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SUMMARY OF INVENTION 

The invention embodied in pending claims concerns a system for reducing errors 
in ordering freight services. (Ex. A; Specification at p. 21, Ins 8-17). Often times when a 
user orders freight services, a wide variety of accessorial services may be ordered at extra 
cost. (Exhibit A; Specification at p. 21, Ins 1-7). Such accessorial services may include, 
but are not limited to, arrival notification, construction site delivery, inside delivery, liftgate 
service, residential delivery, residential pickup, and Saturday pickup. (Ex. A; Figure 7). 

Given the many different options available, it is not surprising that errors arise in the 
proper selection of the accessorial service or in the billing of the service. In fact, errors are 
so commonplace that there is an entire service industry devoted to auditing these types of 
errors. (E A; Specification at p. 21, Ins 1-7). 

To reduce customer related input errors from occurring, the present invention claims 
a system that requires a the user to sequentially address the accessorial services offered 
and to accept or decline each service offered. (Claim 1 ). By requiring the user to address 
the accessorial offered, Applicant has found that billing errors may be reduced. (Ex. A; 
Specification at p. 21, Ins 15-17). 
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STATEMENT OF ISSUES 

The issues for this appeal are: 

1 . Whether the claims are unpatentable as obvious in light of Laverly and Hunt, 
even though there is no motivation to combined the prior art to create the inventions set 
forth in the pending claims. 

2. Whether the Examiner ignored limitations in claim 1 which require that the 
claimed invention is for a system to reduce user errors in ordering freight services and that 
the services are to be sequentially offerred to the user for either acceptance or to be 
declined. 

3. Whether the Examiner's reliance on Laverly was in error since the reference 
is non-analagous prior art. 

GROUPING OF CLAIMS 

The independent claim at issue is claim 1 . All pending claims will stand or fall with 
claim 1 . 
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ARGUMENT 

I. INTRODUCTION 

Despite having already recognized the patentability of Applicant's invention (Ex. B, 

3/13/03 Office Action, p. 5), the Examiner has now, in order to sustain a §103 rejection, 

stretched the teachings of the prior art to the point of distortion, ignored limitations found 

in the pending claims, and applied non-analogous prior art. Thus, as will be demonstrated 

below, the pending claims are indeed patentable. 

A. There Is No Motivation To Combine The Hunt Reference With The 
Teachings Of Laverly 

Long established precedent of the Federal Circuit holds that for a 35 U.S.C. § 103 
obviousness rejection to be proper, the PTO must (1 ) established that the prior art would 
have suggested to one of skill in the art that they should make the claimed invention and 
(2) the prior art would have also revealed that there was a reasonable expectation of 
success in so making the combination. In re Vaeck . 947 F.2d 488, 493 20 USPQ2D 
1438, 1442 (Fed. Cir. 1991). Here, as will be demonstrated below, the Examiner failed 
to cite any support for the conclusion that one of skill in the art would have been motivated 
to combine three distinct pieces of prior art to recreate the claimed invention. 

Central to the Examiner's §103 rejection was a finding that the teachings of the 
Laverly reference (Ex. C) may be combined with U. S. Patent No. 5,835,716 to Hunt (Ex. 

D) and U. S. Patent No. 6,061 ,667 to Danford-Klein to arrive at the claimed invention (Ex. 

E) . Yet, absent in the rejection is any support which establishes that a person of skill in 
the art would have been motivated to combine these three references. The reason for this 
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absence is that the divergent teachings of the prior art would dissuade a person from 

making such a combination. 

For example, as reflected in claim 1 , Applicant's invention concerns a system for 

reducing user related freight shipping errors. This is clearly reflected in the claim itself, 

which reads as follows with relevant parts in bold: 

1 . A computer based system for reducing user errors in ordering freight 
services comprising: 

a) a server computer; 

b) a distributed network connected to the server computer; 

c) a user computer connected to the distributed networkwhich can interact with 
the server computer; 

d) a database on the server computer containing accessorial service 
information; and 

e) programs or software for sequentially displaying a plurality of 
accessorial services and requiring the user to address each of said accessorial 
services offered and to accept or decline said accessorial service s wherein said 
services comprise two or more of the following: arrival notification, construction site, inside 
delivery, liftgate service, residential delivery, residential pickup, and Saturday pickup. 

The prior art, on the other hand, has nothing to do with reducing shipping errors. 

The primary reference, Hunt, does not discuss how to reduce shipping errors. It is 

concerned with a method for brokering carrier capacity. (Ex. D; Abstract). Nowhere does 

Hunt discuss how shipping errors in ordering accessorial services may be reduced. In 

fact, the Hunt reference does not even discuss accessorial services anywhere within the 

specification. The only reference that discusses accessorial services is Danford-Klein (Ex. 

E). However, like Hunt, nowhere in this reference is there any indication that there is a 
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need to reduce errors in ordering these services or that errors even occur. Given that the 

prior art does not even recognize a need for Applicant's solution, it is not surprising that 

the references also fail to teach or suggest any remedy to reduce errors. In short, there 

is no suggestion, or teaching, or motivation to combine in this instance. The same is also 

true for the Laverly reference. 

The Laverly reference, in contrast to Applicant's invention, uses an accept/decline 

function to impose a website's terms and conditions upon a user. Laverly says this may 

be done in a number of different ways. One way suggested is to make the terms and 

conditions conspicuous. (Ex. C at p. 1 , paragraph 4). The other way is to require a user 

either accept or decline the terms by clicking on an appropriate button. (Ex. C at p. 1, 

paragraph 5). If the accept button is selected, access to the website is permitted.id. On 

the other hand, if the terms and conditions are unacceptable, Laverly teaches that upon 

selecting the decline option, a user is denied access to the site and leaves the website: 

Require user agreement before proceeding. Common ways to get a user 
to agree to the terms of use include a button saying "I Agree" or a dialog 
box in which the user must type in his or her name. The user should also 
have the explicit options to reject the terms and leave the Web site, such 
a button saying, " I Do Not Agree." 

(Ex. C)(emphasis added). 

As with the other prior art references, Laverly makes no mention that the disclosed 
accept/decline technique may be used to reduce user related shipping errors. Nowhere 
in Laverly is it ever mentioned or suggested that its teaching may be used in other 
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applications or for other purposes. As Laverly states, it is directed at a solution to control 

the behavior of website users and to protect the intellectual property of the website owner: 

Without clear standards of behavior, users could start the chat room equivalent of 
a saloon fight, or make off like rustlers with a Web site's intellectual property. 
(Ex. C). 

Laverly's solution to control website activity clearly has nothing to do with reducing 

shipping errors. Recognizing that there is no support for a finding that one of skill in the 

art would be motivated to combine these diverse teachings, the Examiner simply filled in 

the blanks by declaring that the motivation exists. The problem, however, is that the 

Examiner did this without citing any specific support in any of the references cited: 

the notion of requiring a user to accept or decline is well known in the art of 
computer programming. Laverly, for example, teaches a system requiring 
user agreement before proceeding, and explicitly requiring the user to 
accept or decline the agreement (see page 1 , 5 th paragraph). The fact that 
the applicant applies this feature within the context of accessorial services 
does not render it patentable over the prior art . It would have been 
obvious to one of ordinary skill in the art at the time the invention was 
made to apply this accept/decline feature of Laverly to the system of 
Hunt et al. Since the basic concept (i.e., requiring a user to accept or 
decline an agreement before proceeding) is well known in the art, and 
since applying this feature to the case of accessorial services is simply a 
specific application of requiring a user to accept or decline information. The 
accept/decline feature, even though applied by applicant to a different type 
of information, does not in itself render the claim patentable over the prior 
art. 

(Ex. B; 3/13/02 Office Action at p. 4) (emphasis added). 

Saying that the teachings of Laverly, Hunt, and Danford-Klein may all be combined 
to recreate the claimed invention without providing any support for such a conclusion 
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makes the rejection improper. For this reason alone the rejection should be reversed. 
There is more. 

The prior art also teaches against combining the references. Applying the Laverly 
system to freight shipping would produce an unworkable result. This is so because Laverly 
teaches that in order to gain access to the site the terms and conditions must be 
accepted. Conversely, Laverly also teaches that if a user declines the terms, access to 
the website is denied (Ex. C). Applying this technique to shipping services would be 
disastrous. What would happen is that once an accessorial service is declined, the user 
must leave the site. The only way for a user to continue processing a shipping transaction 
within the site would be to accept all accessorial services offered. While this may result 
in more business for the shipper, it is a system which is impractical for obvious reasons. 
In other words, Laverly teaches away form the claimed invention, since, if its teaching as 
a whole are applied to shipping services, an unworkable system would result. 

Nor may the complete and entire teachings of Laverly be ignored. By law, a 
reference must be considered as a whole for everything it teaches. It is impermissible 
under §103 to pick and choose from a reference only so much of it as will support the 
Examiner's position, to the exclusion of other parts necessary to a full understanding of 
what the reference fairly would have suggested to one of ordinary skill. Bausch & Lomb. 
Inc. v. Barnes-Hind. Inc. . 796 F.2d 443, 448, 230 U.S.P.Q. 416, 419 (Fed. Cir. 1986); Jn 
re Hedge . 783 F. 2d 1038, 1041, 228 U.S.P.Q. 685. 687 (Fed. Cir. 1986). 
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In short, contrary to the conclusion reached in the Office Action, a person of skill 
in the art would not be motivated to combine the prior art to arrive at Applicant's claimed 
invention. The opposite is true. A person of skill would, in fact, be dissuade from 
combining the references since an unworkable system would result. 

B. The Prior Art Fails to Teach the Claimed Invention 

As set forth in claim 1 , the present invention concerns a system for reducing user 
errors when ordering freight services. This is a specific limitation found in Claim 1 that was 
added by amendment at the request of the Examiner (Ex. C at p. 2). This error reduction 
limitation is simply not found in the prior art. The primary reference, Hunt, does not 
discuss how to reduce shipping errors. It is concerned with a method for brokering carrier 
capacity. (Ex. D; Abstract). The same is also true for the Laverly reference. 

As plainly evident in Laverly, it has nothing to do with freight services. Nor does 
it have anything to do with reducing errors. It is an article written by an attorney 
specializing in intellectual property and on-line transactions that addresses the problem 
of how to impose legal terms on website users. (Ex. C). In fact, not a single reference has 
been cited in any Office Action that addresses how to reduce errors in freight ordering. 
This absence demonstrates that the prior art does not render Applicant's invention 
unpatentable. 

Independent claim 1 also requires the use of "programs or software for sequentially 
displaying a plurality of accessorial services and requiring the user to address each of said 
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accessorial services offered and to acceptor decline said accessorial services...." Again, 
the art of record also fails to teach this claim element. 

As shown above, Laverly cannot teach this claim element since it has nothing to 
do with freight shipping. Laverly's focus is on getting users to agree to the terms and 
conditions of a website - - a one time task that must be completed prior to entering the 
site. (Ex. C). This stands in contrast to the claimed invention which requires that the 
accept/decline technique be applied repeatedly. 

The same is true for Hunt. Hunt, while concerned with shipping services, is 
directed at a system for brokering excess carrier capacity (Ex. D). The only source for any 
teaching on how to reduce shipping errors is Applicant's patent application. In essence, 
what has been done here is that Applicant's own teachings have been read into the prior 
art. 

As the Federal Circuit has held, that is legally wrong. Vandenberg v. Dairy 

Equipment Co. . 740 F.2d 1560, 1564, 224 U.SP.Q. 195, 197 (Fed. Cir. 1984). It is 

improper to use an inventor's patent application as an instruction book on how to 

reconstruct the prior art in hindsight: 

a prior patent must be considered in its entirety, i.e., as a whole , including 
portions that would lead away from the invention in suit, elements of 
separate prior patents cannot be combined when there is no suggestion of 
such combination anywhere in those patents, and a court should avoid 
hindsight. 

PanduitCorp. v. Dennison Mfg. Co. . 81 0 F.2d 1561, 1 568, 1 U.S.P.Q.2d 1 593, 1 597 (Fed. 
Cir. 1987) (citations omitted). Yet, only by making use of the "tempting but forbidden" 
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process of hindsight (see Loctite Corp. v. Ultraseal Ltd. . 781 F.2d 861 , 873, 228 U.S.P.Q. 
90, 99 (Fed. Cir. 1985)) can Applicant's invention be constructed from the teachings of 
Laverly and Hunt: 

To imbue one of ordinary skill in the art with knowledge of the 
invention in suit, when no prior art reference or references of record convey 
or suggest that knowledge, is to fall victim to the insidious effect of a 
hindsight syndrome wherein that which only the inventor taught is used 
against its teacher. 

W.L Gore & Associates. Inc. v. Garlock. Inc. . 721 F.2d 1540, 1553, 220 U.S.P.Q. 303, 
312-13 (Fed. Cir. 1983). 

In short, what has been done in this instance is that the teachings of Laverly have 
b een stretched to the point of distortion and read into Applicant's own specification. 
Laverly clearly teaches that the legal terms of a website may be imposed on a website 
visitor by employing an accept/decline technique. This, however, is not a teaching that 
a system using an accept/decline technique may be used to reduce shipping errors. To 
say that it does simply distorts what the reference actually discloses. Based upon the 
above, the claims are indeed patentable over the prior art. 

II. LAVERLY IS NON-ANALOGOUS ART SINCE IT IS DIRECTED AT IMPOSING 
LEGAL RESTRICTIONS UPON A USER OF A WEBSITE 

Laverly is simply not analogous prior art. In order to cite a reference as prior art for 

purposes of showing obviousness, the Examiner must demonstrate that it is from the 

same fjeid 0 f endeavor or reasonably pertinent to the problem facing the inventor of the 

challenged patent. In re Clay . 966 F.2d 656, 658-59, 23 U.S.P.Q.2d 1058, 1060 (Fed. Cir. 

1992). In Clay , the Federal Circuit held that a reference concerning the use of gel in 
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underground petroleum reservoirs was not prior art to a patent application directed to the 
use of gel in aboveground petroleum storage tanks, even though both activities related 
to the petroleum industry. 966 F.2d at 659-60, 23 U.S.P.Q.2d at 1060-61. See also, in 
re Deminski . 796 F.2d 436, 442, 230 U.S.P.Q. 313, 315 (Fed. Cir. 1986) (reference must 
be within the field of the inventor's endeavor or at least reasonably pertinent to the 
particular problem with which the inventor was involved); A.J. Deer Co. v. U.S. Slicing 
Mach. Co. . 21 F.2d 812, 813 (7th Cir. 1927) (device for cutting logs not analogous to 
device for slicing meat). 

Here, the connection between Laverly and Applicant's invention is even more 
tenuous than in the foregoing cases. As stated above, Laverly deals with how to get users 
to abide by the legal terms of a website and if acceptance is not gained, the user must exit 
the site. Nowhere does Laverly discuss freight shipping services or how to reduce errors 
in this field of endeavor. The two fields of endeavor simply could not be more different. At 
best, a person of skill would look to Laverly as a system that teaches how to impose legal 
or contractual terms on a user. A person of ordinary skill in the art seeking to reduce 
shipping errors, however, would not look to the teachings of Laverly as a solution. The 
Examiner's reliance on Laverly, therefore, is misplaced. 

Nor is Laverly a pertinent prior art reference since it is directed at a different 
problem than that confronting Applicant. As Laverly expressly states, it is directed at 
creating a legal solution for website operators. Applicant's invention, as reflected in the 
claim language itself, is directed at reducing shipping errors associated with a user's 
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selection of accessorial services. Nothing in Laverly suggests that its teachings could be 
used to solve the problems confronting Applicant. As such, Laverly cannot be considered 
as prior art in this case. Thus, the rejection should be reversed. 
III. CONCLUSION 

For the reasons stated above, the claims should be found allowable once again. 




NIRO SCAVONE HALLER & NIRO 
181 W. Madison Street, Suite 4600 
Chicago, Illinois 60602 
(312) 236-0733 

Dated: April 28, 2003 
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APPENDIX 

1. A computer based system for reducing user errors in ordering freight 
services comprising: 

a) a server computer; 

b) a distributed network connected to the server computer; 

c) a user computer connected to the distributed networkwhich can interact with 
the server computer; 

d) a database on the server computer containing accessorial service 
information; and 

e) programs or software for sequentially displaying a plurality of accessorial 
services and requiring the user to address each of said accessorial services offered and 
to accept or decline said accessorial services wherein said services comprise two or more 
of the following: arrival notification, construction site, inside delivery, liftgate service, 
residential delivery, residential pickup, and Saturday pickup. 

2. The system of claim 1 wherein each accessorial service must be addressed 
individually. 

3. The system of claim 2 wherein each accessorial service must be addressed 
individually. 

6. The system of claim 1 wherein the accessorial services are presented as a 

list. 
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Field of the Invention 

5 The invention claimed relates to computer networks, and particularly, to marketing over 

computer networks and to network marketing and provision of freight trucking services. 
Background of the Invention 

Historically, less-than-truckload ("LTL") freight trucking services have been rated and 

i 

scheduled by phone calls to individual carriers or brokers, and confirmatory faxes or letters. As a 
1 0 result, the time involved in obtaining competitive quotes, scheduling the shipments, billing, tracking 
and confirming shipments has been significant. In addition, invoices, bills of lading and other 
important documentation have often contained mistakes or errors, leading to further time spent 
rectifying any problems. Because of the often personal nature of the quotes provided, it has been 
difficult to obtain accurate quoting services and rapid scheduling, and impossible to obtain a choice 
15 of freight trucking services from a single-source real-time network-based solution. In addition, 
significant errors in billing often occur with respect to accessorial services which include, among 
others, arrival notification, inside delivery and liftgate services. Often, a customer fails to notify the 
shipping agent that such services are desired or the shipping agent inputs the incorrect information 
while taking the order. These types of errors are so pervasive in the shipping industry that entire 
2 0 service companies exist to audit shipping invoices to correct these types of errors. Another error that 
is common is to enter an incorrect zip code for the delivery location. This again leads to both 
delivery problems and to billing inaccuracies similar to those described above. 
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Freight trucking services ordinarily consist of: rating, scheduling, tracking, confirming, and 
billing. Other related services can also be provided. It is useful to be able to see or generate reports 
of shipments made or in progress. 

Rating the shipment involves providing information to the carrier or broker regarding the 
5 origin, destination, and kind of shipping desired. The carrier or broker then determines the rate, 
often with a negotiated discount, and quotes the rate to the user. The user will then schedule the 
shipment's pickup and delivery, if the rate is acceptable. It is useful for the user to be able to track 
the shipment, which is to be able to ascertain the transit status of the shipment once the order has 
been placed. Tracking services provided to the user are commonly based on a shipment number, 
1 0 which the user must have or look up if the user wishes to track a package. These tracking services 
allow the user to track single packages, based on the tracking number alone. 

If a broker is used, the broker will need to confirm the shipment with the carrier in order to 
verify that the carrier will have capacity to handle the shipment. Again, this process typically 
involves telephone calls, faxes, and person-to-person contacts. These contacts lend inefficiency, 
15 inaccuracy, and time to an already cumbersome system, but are typically the way freight trucking 
shipments are rated and scheduled currently. 

In freight trucking, volume discounts are often given by carriers in order to induce users to 
ship with them, and reward repeat business. These discounts can amount to up to 70% of the 
carrier's base tariffs, and often result in substantial savings to those shippers able to get such 
2 0 discounts. These discounts are not typically available to individual users, other than based on their 
individual volume of shipments. Sometimes, these volume discounts may be granted to a broker, 
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who may pass a portion of the discount on to the broker's users, or to a group of similarly situated 
shippers. 

A number of network-based shipping services have come into being in recent years. These 
services, typically, perform the same services provided by a carrier, but over the Internet or other 
5 network. Typically, the services provided will be a simple quoting or rating service, along with a 
scheduling request. No services provide real-time rating and scheduling of shipments or customized 
branding and reporting by user. 

While a number of specialized network-based services have been developed for target 
markets such as network-based auctioning, retail sales, or grocery shopping, no advanced system for 
1 0 providing general freight shipping services over a network has been developed. 

Additionally, existing network-based services generally have a model which is used for 
providing services. Such a service will be provided with either a single affiliation or a banner 
advertisement which will be determined randomly at the time a user accesses the service. Hence, 
a web site or other network-based service will have advertisements or affiliations, but these 
1 5 affiliations and advertisements will be statically determined or based on random selection. In other 
words, a single web-site or network-based service will appear to be affiliated with only one group 
or organization, and though it may have a plurality of advertisers, those advertisers may appear as 
a group or in banner advertisements. 
Definition of the Terms 

20 The following terms are used in the claims of the patent as filed and are intended to have 

their broadest equivalent meaning consistent with the requirements of law. 
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"Affiliation" or "Association" means an organization or group of which a user may be a 
member. 

"Affinity group" or "affiliation group" means a group with similar interests, such as a 
professional organization or other group. Any group of users may be referred to as an affinity group 
or affiliation group. 

"Branding" means marking or displaying an affinity or affiliation indication or associating 
a service with an affinity or affiliation. 

"Carrier SCAC" or "SCAC" means or any code or abbreviation used to represent a carrier. 

"Carrier information" means any data or information stored in the database regarding the 
carriers. This may include SCAC, rate information, discount information, markup information, or 
any other kind of information related to a carrier. 

"Customer information or user information" means any data or information stored in the 
database regarding the customer. 

"Customer" means a user who has been registered with the service, and has access to a master 
account or a sub-account. 

"Database" means a collection of information stored in a format which allows searching by 
a computer, program or user. 

"Freight trucking" means land-based shipping of full or partial loads by any shipping vehicle, 
such as a truck, automobile, panel van, or other shipping vehicle. 

"Freight trucking" means shipping performed over land, using trucks, either the entire truck 
or a portion thereof. 
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"Freight marketing" means the marketing of freight trucking services. 
"HTML" means Hypertext Markup Language. 

"LTL shipping" means "less-than-truckload" shipping, or shipping involving any size load, 
including specifically loads with are less than an entire truckload. This definition is meant to be 
5 inclusive rather than exclusive, and also includes loads which are equal to or greater than an entire 
truckload. 

"Marketing" means advertising, selling, providing, or any combination thereof. 
"Master Account" means an account on the Service affiliated with a single user. An account 
will usually include a personal identification, such as a name or code, and a password or PIN. This 
10 account will grant access to the Service upon the entry of the personal identification and the 
password or PIN, though it may involve any kind of mechanism for identification of the user, such 
as a password or account name alone, or a name paired with a "cookie" provided by the user's 
computer, or any similar device. 

"Network" means any distributed computer network, including, without limitation, both 
15 private and public networks, such as IPX networks or the Internet. 

"NMFC number" means National Motor Freight Classification number, but may also indicate 
any code in any system for classifying freight shipments. 
"OCR" means optical character recognition. 
"PIN" means personal identification number. 
2 0 "POD" means proof of delivery or proof of delivery form. 
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"Programs" or "software" means any machine-operable code stored on a computer permitting 
it to operate or perform a function. 

"Quotation" means a price quote for a service, such as a shipment. 

"Rating" means quoting a price based on shipment data provided by a customer or user, such 
as a stated shipment type, origin, and destination, 

"Shipper" means the location, entity, user, or person from which a shipment is picked up or 

sent. 

"Sub-account" means a sub-division of a master account. These sub-accounts may be 
accessible by the Master Account's user through use of a separate password or PIN. 

"The service" means the service for providing services related to freight trucking over a 
distributed network such as the Internet or World Wide Web, or any other distributed network. 

"The system" means the computer hardware and software used in providing the service. In 
the currently preferred embodiment, this includes the server computer. 

"The server" means the computer hardware used in providing the service. This may include, 
as in the currently preferred embodiment, a web server and a database server. The server may also 
be a single computer or a plurality of computers. 

"Carrier" means an individual or organization providing freight shipping services. 

"Tracking" means providing information regarding shipment status. 

"User" means customer, potential customer, or other person accessing the service. 

"Web browser" means any software adapted for accessing web pages or other files over the 
Internet or a distributed network. Examples of such software are Netscape Navigator and Internet 
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Explorer. Where alternative meanings are possible, the broadest meaning is intended. All 
words used in the claims are intended to be used in the normal, customary usage of grammar and the 
English language. 
Summary of the Invention 

The invention provides a novel system and method for affiliation of a service provided over 
a network with a plurality of entities and a novel system and method for providing customized 
shipping quoting, scheduling, tracking and reporting. 

A novel feature of the invention is the custom branding of the services provided with an 
association, affinity group, or organization logo and name, ascertained from information provided 
by the user. Any service provided may appear to different customers or users to be provided by or 
affiliated with different associations, organizations or affinity groups. This feature is novel with 
respect to all services provided over a distributed network. 

The invention allows a user to obtain actual quotes for LTL shipping from a plurality of 
carriers. The user may then schedule the pick-up and shipment from the shipper of choice, and 
generate a bill of lading and customer invoice. The user benefits from group or other discounts 
provided by the service or their affiliation, and may choose the most favorable rate from among a 
number of shippers, or may choose a favored shipper based on criteria of the user's choice. The user 
is able to obtain an actual rate, incorporating any discounts, and can see precisely the amount which 
the user will pay if the user elects to use the shipping service quoted. 

The invention maintains a database of carriers, and upon receiving a rating request from a 
user, queries the database in order to determine which carriers will provide service. The system then 
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determines the rate applicable to each carrier, based on any volume discounts provided and 
applicable markups, and quotes the rates of all applicable carriers to the user. Once the rating 
process is completed, the user may choose the carrier it wishes to use for the shipment, and schedule 
the shipment. 

The invention permits the user to select from a plurality of features or accessorial services 
for the shipping services chosen, such as arrival notification, inside delivery, liftgate services, or 
others. The charges for these features or accessorial services are automatically calculated and 
displayed to the user. Moreover, inaccuracies with respect to the accessorial service charges are 
further reduced by requiring the user to address each accessorial service individually before the user 
may exit the accessorial page and move further through the system. 

The invention permits the user to rate and schedule either a single shipment or a plurality of 
freight shipments at one time. 

Yet another aspect of the present invention is to reduce errors resulting from inputting 
incorrect zip code information. This may be accomplished by comparing the inputted delivery 
location zip codes with stored delivery location zip coded used by the shipper in the past to 
determine, if the zip code information inputted reconciles with locations used in the past. 

Another feature of the invention is the ability to customize the interface for each customer 
or user, permitting the quoting service to recall for the customer or user their prior orders, and data 
provided earlier by the user. The system dynamically stores shipping addresses and other data for 
each user, permitting the user to schedule later shipments to or from repeated addresses, bill repeat 
customers, or perform any repetitive task without requiring the user to supply information again. 
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This feature is novel in the area of freight services marketing over a distributed network, and has 
numerous novel aspects. 

An aspect of the customization is the ability to generate specific management reports, 
specifically permitting the user to create and run customized reports, which can then be transmitted 
to the user either over the network, via electronic mail or facsimile. These reports can cover 
shipment tracking, shipment usage, or other features of the service, can be run both by user request 
and automatically, and can cover shipments already invoiced and not yet invoiced. 

Another aspect of the customization is the ability for each user to maintain sub-accounts for 
each master account. A user may have multiple sub-accounts for each master account, with each 
sub-account having its own password or PIN. These accounts may be associated with different 
employees of the user, different customers of the user, or any categorization which the user desires. 
This permits the user to restrict access to certain information or to more easily track different uses 
of the service. 

Another aspect of the customization permits the user, once the user has scheduled shipments, 
to access a tracking report or shipment log of all prior shipments. These shipments may be tracked 
by the user without reference to a specific shipment number or code, and permits the user to access, 
both by user and by sub-account, records of all shipments scheduled through the service. Individual 
shipments may also be tracked without the use of a tracking number or code. 

Another aspect of the customization permits a user to access invoices, past and present, 
including payments and credits. The user may also view payment and credit details on a monthly 
basis. Another aspect of the service permits the user to maintain and utilize a database of NMFC 
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numbers for the products shipped, allowing the user to accurately rate and schedule shipments based 
on both standard product descriptions and their own customized product descriptions, with 
appropriate NMFC numbers provided automatically by the system. 

Another aspect of the service permits the user to create and print invoices for the user's own 
customers. These invoices may be printed while the user is accessing the service upon scheduling 
a shipment. The service stores customer information for each user, which the user may access for 
repeat shipments. The invoices are custom-generated for the user, and the system permits the user 
to add their cost to the cost of the freight, thereby permitting a completely custom invoice. The 
invoices are printed on a ready-to-mail form for the convenience of the user. 

Another aspect of the invention is automated pickup confirmation. The system either 
electronically notifies or faxes the carrier chosen by the user with an automatically generated pickup 
confirmation request. The fax request contains check-boxes for the carrier to mark, indicating 
whether the carrier will be able to handle the shipment or not. The carrier then faxes the request 
back to the service. The service automatically recognizes the pickup confirmation request using 
OCR software and updates the system automatically to reflect the carrier's reply. The user may 
access the system at any time to determine whether or not the user's shipment has been accepted, and 
track the shipment's status. 

The system will also permit the user to print a Bill of Lading. In addition, if the user is not 
the shipper, the system can automatically fax a Bill of Lading and pickup instructions to the shipper. 

The entire process of rating and scheduling a shipment may be performed by the user via 
access to the system. No telephone calls need be made, no confirmatory faxes or letters are sent by 
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the user. The user can rate, schedule, bill and track an entire shipment through access to the system, 
and generate custom reports regarding the user or any sub-accounts regarding the use of the system. 
Thus, the invention is a single-source, network-based solution for marketing freight trucking 
services. 

Brief Description of the Drawings 

Figure 1 shows an overview of the system, including the user computer, a network, and the 
service's server computers. 

Figure 2 shows an overall flowchart of the service, from a user's point of view. 

Figure 3 shows the login page for a web-based version of the invention. 

Figure 4 shows the main menu page for a web-based version of the invention. 

Figure 5 shows the rating page for a web-based version of the invention. Figure 5 A shows 
an example of a multiple class entry page. 

Figures 6 and 6A show the address information page for a web-based version of the 
invention. 

Figure 7 shows the accessorial services page for a web-based version of the invention. 
Figure 8 shows the product description page for a web-based version of the invention. 
Figure 8A shows a shipment ready page for a web-based version of the invention. 
Figure 9 shows the third-party invoice page for a web-based version of the invention. 
Figure 10 shows a specimen invoice. 

Figure 11 shows the complete shipment page for a web-based version of the invention. 
Figure 12 shows a sample Bill of Lading. 
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Figure 13 shows the invoice inquiry page for a web-based version of the invention. 
Figure 14 shows the shipment tracking page for a web-based version of the invention. 
Figure 15 shows the customized reports page for a web-based version of the invention. 
Figure 15 A shows a run cost report page for a web-based version of the invention. 
Figure 15B shows a sample cost report. 

Figure 15C shows a run tracking report page for a web-based version of the invention. 
Figure 15D shows a sample tracking report. 

Figure 16 shows the manage sub-accounts page for a web-based version of the invention. 

Figure 17 shows the LTL rating process. 
Detailed Description of the Preferred Embodiments 

Set forth below is a description of what is currently believed to be the preferred embodiment 
or best example of the invention claimed. Future and present alternatives and modifications to this 
preferred embodiment are contemplated. Any alternatives or modifications which make insubstantial 
changes in function, in purpose, in structure or in result are intended to be covered by the claims of 
the patent. 

The invention's preferred embodiment currently is a web site, and may best be understood 
in terms of use over the Internet. It can readily be seen, however, that the essential design of the 
system and the services provided by it do not require the use of a web site over the Internet, but may 
be implemented through the use of any server over any network, including the Internet, an IPX 
network, or any distributed network of computers with access to a server or computer on which the 
system operates. The system providing the services of the invention may comprise a number of 
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computers, such as a web server and a database server, or a single computer performing all of the 
functions of the invention, so long as the user may access the functions over a network. 

The present preferred embodiment of the system is the preferred embodiment given the 
present technology available and the kinds of networks currently in popular use, and is not meant 
5 to restrict the specification or practice of the invention in any way by reference to a specific kind of 
network, server, computer, or operating system. Equivalent computers, networks, or operating 
systems are expressly contemplated by the invention, and could be used to practice the invention. 

In Figure 1, the overview of the system is shown. The system server, including web server 
1 and database server 2, permits users to access the services over the Internet 3 from any user 

10 computer 4 connected to the Internet. This connection may be via modem, DSL, Ethernet or any 
other connection. The user connects to web server 1 using the web browser of their choice. 
Examples of such browser programs are Netscape Navigator or Microsoft's Internet Explorer. It can 
readily be seen that access may also be by dedicated connection or direct dial-in, or any web browser 
software could be used to access the server in an alternate embodiment. In the present embodiment, 

15 it is preferred to use Internet Explorer or Netscape Navigator, which are the two most popular 
browsers in common use at the present time. Web server 1 is itself connected to database server 2, 
which performs the storage, query, and lookup functions of the invention. It can readily be seen that 
a single, more powerful computer could perform the functions of both web server 1 and database 
server 2, or that more than two computers may be used to perform the functions of the service. Any 

20 of user computer 4, web server 1, or database server 2 may also be protected by a firewall or other 
device without affecting the invention, so long as the system server is accessible by the user 
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computer. The database may be kept and required lookup functions performed via a variety of 
common web and database server programming methods. Individual lookup or searches of the 
database are not described in this description, as they are easily within the scope of one of ordinary 
skill in the art. The currently preferred embodiment of the invention uses Oracle 8.0 database 
5 software and Microsoft' s Internet Information Server web server, but any similar server and database 
software may be used, and custom written software may be used in order to practice the invention. 
The use of any specific software or lookup table is not meant to limit the scope of the invention, but 
only as an example of the currently preferred embodiment. It is worth mention that the use of a web 
server and a database server or their equivalents are well known in the art, and where the 

10 specification calls for the database server, the web server, or the system, to perform a function 
without further description, the actual operation or programming of the system to perform the action 
or function described is well known in the art, and will be readily apparent to one skilled in the art. 
In the currently preferred embodiment, the servers used are as described, and the web pages 
themselves are programmed in HTML. Oracle is used to maintain the database of information, 

15 which permits the service's operators or administrators to alter the customer information, carrier 
information, rate information and other information stored within the database. 

Figure 2, shows a flowchart of a possible presentation of the system to the user, in the 
currently preferred embodiment. The user enters the service by accessing a login page 5 via the 
user's web browser. On that page, one possible example of which is shown in Figure 3, the user 

2 0 enters the user's access code 23 and PIN 24. If the user is a prospective customer or has no access 
code, the user is given a promotional tour of the features of the service. If the user is an existing 
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customer, the user is redirected to the user main menu page. Figure 3 shows one example of a 
possible login page. 

If the user is a customer, the customer will be redirected to the customer main menu 7 instead 
of the tour. Once on the customer main menu page, which is shown on Figure 4, the user is 
permitted to follow links in order to rate and schedule shipments 8, view shipment logs 9, view 
management reports 10, or review invoices 1 1 . Links for each choice are provided on the main menu 
page. If the PIN 24 entered by the user on the login page indicates that a sub-account is to be used, 
access will be granted only to the sub-account's information. 

As seen in Figure 4, every page which a user may visit may be custom branded with a special 
logo in the affinity indication portion 24 of the page. This logo will be based on the user's 
affiliation. For example, if the user is a member of the ABC Association, which the service 
determines based on the user's master account, the ABC Association's logo or title will be placed 
in the affinity indication portion 6 of each page during all access. This is true even of the tour, if the 
tour is the result of access based on a promotional flyer with a user code. The user enters the code, 
which begins the tour. The tour will be affinity branded based on the code entered. This permits 
affinity groups to market specifically to their members, with every aspect of the web site branded 
to their group. 

If the user chooses to rate and schedule shipments, the user will be led through a series of 
pages for rating, scheduling, invoicing, and confirming the shipment. First, the user will be directed 
to the rate page 8, where the user may rate a shipment or a plurality of shipments. The user will then 
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be allowed to schedule any of the shipments, and will be led through the scheduling process for each 
shipment. 

For each shipment, the user will be led through the following process, and may either confirm 
and send or cancel each shipment: 
5 The user will be directed to the Schedule 1 page 12, where the user may enter new shipping 

information or recall old shipping information in order to schedule the shipment or shipments. If 
the user enters new information, the system will store the new shipping information for future recall 
during the Schedule 2 13 phase, as the user is directed to the additional services page at Schedule 
3 13, where the user may choose accessorial services for each shipment. After choosing accessorial 

1 0 services, the user will be directed to choose a product description for the shipment on the product 
description page in the Schedule 5 phase 15. The user may add or re-use product description, and 
the service will save any new product designations for future use. The user then schedules the 
pickup, on a scheduling page in the Schedule 6 phase 16. The user may create an invoice to bill the 
user's customer in the Schedule 6 phase 17, which the user may print out directly from the browser 

1 5 during the Print Invoice phase 18. If the user confirms the shipment on the confirm shipment page 
19, the user prints a Bill off Lading (Print BOL 20), the system faxes a Bill of Lading to the shipper 
if the shipper is different from the user, and the user may begin scheduling the next rated shipment, 
if any. 

If the user has completed scheduling or canceling all rated shipments, the user is returned to 
20 the Customer Main Menu 7. 
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I now describe the individual pages of the system, commencing with the scheduling pages. 
These pages are described in the same order they were discussed, and appear in Figure 2. 

Figure 5 shows a web page designed for rating a single shipment or a plurality of shipments. 
For each shipment the user wishes to have rated, the user may enter the origin zip into an origin zip 
entry box 30, the destination zip into a destination zip entry box 31, select a class from a class drop 
down box 32, and enter the total weight in a total weight entry box 33. If the user chooses 'multiple' 
from drop down box 32, the user will be redirected to the multiple shipment information page (Fig. 
5A). Once the user has entered the multiple class information for the shipment, the user will be 
returned to the rating page shown at Figure 5, which will now show the 'multiple' class for the 
shipment, and the total of the weight information entered in the multiple shipment information page. 
Upon entering all of the information and pressing the rate button 34, the system will rate the 
shipment according to the rating system described below (and shown in Fig. 17), and report the 
carrier in the carrier column 36 and that carrier's rate in the price column 35, along with the 
estimated time of transit in the estimated transit column 37. When the user has rated all the 
shipments desired, up to a maximum of ten in this embodiment, the user may choose which, if any 
of the shipments, to schedule. The user clicks 'yes' or 'no' in the radio buttons 39 in the arrange 
pickup column 38. Upon clicking the next button 40, the scheduling process will begin. 

For each shipment, the user will follow the scheduling process, as described above, and 
shown in Figure 2. The first page shown to the user is the address information page, shown in Figure 
6. This page permits the user to enter new addresses or access existing addresses in any convenient 
format. First the user will choose whether the user is the shipper, receiver, or a third party for the 
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shipment, using radio button 41 A. At Figure 6A, the page is shown for the user as shipper. The user 
will enter or recall address information for the shipper and the recipient of the shipment. In the 
current preferred embodiment, existing addresses may be accessed through a drop down box 
associated with company name entry boxes 43 and 44. These entry boxes permit the user to type in 
5 a new name, or, if existing companies are stored in the database server 2, to access existing addresses 
by using the drop down box. If the drop down box is used, the remainder of the information in either 
shipping address box 41 or receiving address box 42 will be entered automatically by the web server 
1 and database server 2. Any format may be used for address information. The currently preferred 
embodiment suggests a format of Company, Street Address 1 and 2, City, State, Zip, Phone, Fax, 

10 Contact Name and Shipper Reference. The database of address information stored in the database 
server 2 stores the information by user and sub-account, if used, and permits the system to provide 
address storage to each user and sub-account. 

As an additional verification step to reduce shipping errors, the receiving address data such 
as the zip code is compared against stored data for reconciliation. If the newly inputted information 

1 5 matches previously inputted information, no action is taken by the system. On the other hand, if an 
inconsistency is detected, such as an incorrect street number or zip code, the user will be prompted 
to verify that the correct information has been supplied. This may be done by simply having the user 
re-input the information or displaying the previously entered information so that a comparison may 
be made. Of course, the system may also prompt the user to select between the stored data and the 

2 0 new user input to make any needed reconciliation. Moreover, the system may also be programed to 
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allow the user to further edit the information stored by either editing the stored data or using the new 
user input as further new user input. 

The shipment information box 45 permits the user to see information sufficient to indicate 
which shipment is currently being scheduled. In the currently preferred embodiment, the information 
presented is the carrier and carrier SCAC, origin and destination zip codes, weight, class, cost, fees, 
and estimated time of transit. It may readily be seen that the information presented need only be 
sufficient to identify the shipment, and need not necessarily be the same as that shown in the 
currently preferred embodiment. If the user is the shipper or the recipient, the user's information will 
automatically be shown in boxes 41 or 42, as appropriate. If the user is a third party, the user's 
address information may be shown in a third box, and the user will choose or enter address 
information for both boxes 41 and 42. The next button 46 allows the user to proceed to the 
accessorial services page and the back button 47 allows the user to return to the rating page. 

The accessorial services page is shown as Figure 7. The same information is shown in the 
shipment information box 45. The check boxes 50 each correspond to an accessorial service. It can 
readily be seen that the accessorial services 51 may be any set of accessorial services commonly 
offered by carriers. Upon the user checking one of the check boxes 50, the corresponding additional 
charge 52 will be shown next to the corresponding accessorial service description 51 and, in the 
currently preferred embodiment, added to the Additional Fees section of shipment information box 
45. The charges are determined by the service's database server 2, and displayed by the web server 
1. Thus, it is readily seen that the user, at all times, can see the exact price currently offered by the 
service for the shipment. 
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It is in this area of accessorial service charges that frequent billing errors occur. Billing errors 
of this type are so prevalent in the shipping industry, as a result of customer error or error by the 
shipper in properly inputting the data on the order, that an entire service industry to audit these types 
of errors has been created. These types of companies compare the invoices to the actual shipping 
data to determine if over-charges had been made. For example, charging for an accessorial service 
not provided or ordered. It is estimated that the these types of errors are in the hundreds of millions, 
if not more, given the size of this industry. 

To reduce customer related input errors from occurring, the system may be programmed to 
require the user to address each accessorial service 51 listed. In operation, each check 50 is 
sequentially addressed with the user being required to indicate whether or not each accessorial 
service is required. Once each check box 50 is addressed, the user may then click the next button 
48 to proceed to the product description page, or the back page button 49 to return to the address 
information page. Because of the importance of obtaining accuracy with respect to the accessorial 
services, the system may be programmed to prevent the user from moving further back or forward 
through the system until each accessorial service is addressed. In summary, it has been found that 
billing errors associated with accessorial services may be reduced by requiring a user to accept or 
decline each service before permitting the transaction to be completed. 

In addition, a further benefit may be provided to the user in the form of a list or summary of 
accessorial services selected and services rejected. This is yet another verification step that has been 
found to reduce errors. As a further requirement, the system may also be programed to prevent the 
transaction from being completed until at least one element of the accessorial service list has been 



DOCKET N0.2799CIP 

selected by the user, or that no service has been affirmatively selected by the user. Lastly, the system 
may also be programed to prevent a transaction from being completed until all listed accessorial 
services have been addressed by the user. 

The product description page is shown at Figure 8. This page allows the user to enter product 
descriptions for each class of product in the shipment. A product description drop down box 55 
permits the user to use already available descriptions, or to store new descriptions in the database. 
If the user wishes to use a pre-existing description, the user simply chooses it using the product 
description drop down box 55. If the user wants to add a new description, the user simply chooses 
4 Add a Product' or a similar designation from product description drop down box 55, and types in 
the new description. The user will then choose an NMFC number to associate with the product, and 
enter the NMFC number in NMFC number box 58. If the user uses a pre-existing product 
description, the service will automatically use the NMFC number associated with that description 
in the database. Class and weight are shown in class display column 56 and weight display column 
57. Class and weight are both shown for each portion of the shipment based on the information from 
the shipment rating page. The user may also check a hazardous materials check box 59 for any 
portion of the shipment. The price of the shipment will be automatically recalculated by the service 
and displayed in shipment information box 45. The user will also indicate, from a package type drop 
down menu 60 the type of package used with each portion of the shipment, and in a number of 
packages entry box 61 the number of packages of each type. Once all of these decisions have been 
made for each portion of the shipment, the user may click on next button 53 to proceed to the 
shipment ready page. The user may also click, at any time, on back button 54 to the accessorial 



DOCKET N0.2799CIP 

services page. The shipment ready page (Fig. 8A) simply permits the user to indicate, via drop down 
boxes 54B, 54C, and 54D, the time the shipment will be ready for pickup. Any equivalent method 
could be used. Next button 53A allows the user to proceed to the third-party invoice page, while 
back button 54A returns the user to the product description page. 

The third-party invoice page is shown at Figure 9. This page allows the user to prepare an 
invoice for a third-party for each shipment scheduled, if desired. If the user wishes to print a third- 
party invoice, he may do so using invoice radio button 62. Using discount radio button 63 the user 
determined whether or not to pass on the discounts received from the service to the customer. In 
third-party address box 64, the customer chooses or enters address information for the third-party 
to receive the invoice, in the same manner as shown above. As above, the service permits the user 
to recall old third-party information by accessing the database server 2 via a drop down menu or 
enter new address information. Once the user has completed any necessary entries on this page, the 
user may click on next button 66 to proceed. The user may also click, at any time, on back button 
67 to return to the shipment ready page. 

If the user has chosen to print a third party invoice, upon clicking next button 66, the user will 
be presented with a specimen invoice, which the user may then print. Such a specimen invoice is 
shown at Figure 10. The user may click on print button 68 to print the invoice, then next button 69 
to proceed to the complete shipment page. The user may also click on back button 70 to return to 
the third-party invoice page. 

The complete shipment page is shown at Figure 11. This page presents the user with a final 
opportunity to cancel the shipment. If the user clicks on cancel movement button 71, the user will 
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cancel the shipment and proceed to scheduling the next shipment or return to the main menu if there 
are no further shipments to schedule. If the user clicks on ok button 72, the shipment will be 
ordered, and the user will be presented with a Bill of Lading to review. A sample Bill of Lading 
page is shown at Figure 12. Any reasonable bill of lading format could be used. In this example, 
when the user clicks on print button 73, a bill of lading will be printed on the user's printer. The user 
may print as many copies of the BOL as needed, and then click on the next button 74 in order to 
proceed. If the user has rated shipments remaining to schedule, the user will be returned to the 
address information page to schedule the next shipment. If there are no remaining shipments to be 
scheduled, the user is returned to the main menu page. 

There are three options other than rating and scheduling shipments available to the user from 
the main menu page (Fig. 4). If the user clicks on invoice inquiry button 26, the user will be 
redirected to the invoice inquiry page (Fig. 13). If the user clicks on shipment logs button 27 the user 
will be redirected to the tracking shipments page (Fig. 14). If the user clicks on customized reports 
button 28 the user's browser will be redirected to the customized reports page (Fig. 15). 

Each of these pages performs a different function. The invoice inquiry page (Fig. 13) permits 
the user to review the status of all service invoices. This permits the user to view the current status 
of their account with the service. Invoices in the currently preferred embodiment are displayed by 
invoice number, and show the date of the invoice, the due date, the prior balance, payments or 
credits, and the total due. Any reasonable alternate format could be used to present the data, and the 
data could be presented in any reasonable tabular format. The scroll bar 75 in this embodiment 
permits the user to scroll through the available invoices. The data is stored on the database server 
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2. Upon receipt of payment, the service will update the database server 2 to reflect the payment. 
This can be performed by a direct database operation, or any software adapted for the purpose of 
making changes to the database. A separate administrative web page, program, or server are three 
alternatives available in the present state of the art. 
5 The shipment tracking page (Fig. 14) permits the user to review the status of all shipments 

made by the user. This permits the user to view the current status of their shipments. Shipments in 
the currently preferred embodiment are initially displayed by the BOL number generated by the 
service, and the display shows the SCAC of the carrier performing the shipment, the date of the 
pickup, the date and time of the delivery, and the name of the recipient of the shipment Any 

10 alternate format could be used to present the data, and the data could be presented in any format. 
The currently preferred embodiment displays the data in a tabular format. The scroll bar 76 in this 
embodiment permits the user to scroll up and down through the available shipments. In addition, 
if the user clicks on any of BOL number column heading 77, SCAC column heading 78, status 
column heading 79, pickup column heading 80, delivered column heading 81, signature column 

15 heading 82 or time column heading 83, the database server 2 will sort the shipments by the data 
contained in the column, and web server 1 will display shipment data in the resulting order. The data 
is stored on the database server 2. Upon receipt of new information, the service will update the 
database server 2 to reflect the payment. This can be performed by a direct database operation, or 
any software adapted for the purpose of making changes to the database. A separate administrative 

2 0 web page, program, or server are three alternatives available in the present state of the art. In 
addition, the carriers themselves could be given limited access to the database via a customized web 
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page to update information for shipments made by each carrier. Print BOL button 84 permits the 
user to reprint the BOL for a selected shipment by clicking on the shipment's row and then clicking 
on print BOL button 84. Print POD button 85 permits the user to print a POD report for a given 
shipment, again by clicking on the shipment's row and then clicking on print POD button 85. 

The customized reports page (Fig. 15) permits the user access to cost reports, tracking 
reports, and custom reports for an account or sub-account. The user may choose any kind of report 
to generate or to schedule. If the user clicks on cost report button 86, 87 or 88, the user will be given 
the opportunity to choose a location from the database of all locations shipped to or from. After 
choosing a location, the report will be printed, or scheduled to be run at a future time. By clicking 
on cost report button 86, a report may be generated and may be printed for all shipments not yet 
invoiced to or from the location chosen. An example of the currently preferred run cost report page 
is shown at Figure 15A, and a sample cost report is shown at Figure 15B. By clicking on cost report 
button 86, the user is redirected to a run cost report page. After filling in the information requested 
in origin zip box 87A and destination zip box 87B as well as date range start box 87C and date range 
stop box 87D, the user may indicate which method the user prefers to receive the report by, fax or 
email by clicking on radio buttons 87E. After entering the destination information in box 87F or 
87G, a report is generated when the submit button 87H is clicked by the user, and the report is 
delivered via the method indicated by the user for any invoices in the date ranges chosen by the user 
for shipments to or from the location chosen. The report may be of any reasonable format, but the 
currently preferred format is shown in Figure 15B. The reset button 871 clears all fields. When the 
user clicks on cost report button 87, the report may be generated for all shipments already invoiced 
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to or from the location chosen, using a run report page similar to that shown in Figure 15B. When 
the user clicks on cost report button 88, either of these reports may be scheduled to be run at a future 
time and shipped to the user via facsimile or e-mail, using a scheduling report page similar to the one 
shown in Figure 15B, with the addition of date and time entry boxes to allow scheduling a future 
report run. The service will fax the report or e-mail the report over the distributed network at the 
time scheduled, automatically. 

Likewise, if the user clicks on tracking report button 89, 90 or 91, the user will be given the 
opportunity to choose a location from the database of all locations shipped to or from. After 
choosing a location, the report may be printed, or scheduled to be run at a future time. By clicking 
on tracking report button 89, a tracking report may be generated and may be printed for all shipments 
not yet invoiced to or from the location chosen. By clicking on tracking report button 90, a report 
is generated and may be printed for all shipments already invoiced to or from the location chosen. 
When the user clicks on tracking report button 91, either of these tracking reports may be scheduled 
to be run at a future time and shipped to the user via facsimile or e-mail. A sample of a tracking 
report page is shown at Figure 15C, which operates similarly to the cost report pages described 
above, again with the addition of date and time entry boxes for future scheduling. An example of 
a tracking report in the currently preferred embodiment is shown at Figure 15D. Both the tracking 
reports and the cost reports may be in any reasonable format. 

As is shown, it is also possible to permit custom reports to be designed or run, using custom 
report buttons 92, 93 or 94. These buttons may permit the user to design a custom report based on 
any of the data stored in the database. These custom reports can then be run just like the tracking 
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and cost reports, either instantly or on a scheduled basis, with facsimile or e-mail delivery. 
Additionally, the user could request a special report to be designed, which would then be accessed 
via these boxes, similarly to the reports described above. 

The manage sub-accounts page (Fig. 16) may be reached by the user by directing their 
browser to the enrollment page. The manage sub-accounts page permits the user to create sub- 
accounts for master account information entered in master account information box. The user enters 
their access code in access code box 95 and their PIN in PIN box 96. The service will recall and 
display the user's information in user information box 97. The user may then access the sub-account 
management functions of the page. These may be presented in any reasonable format. In the 
currently preferred embodiment, the sub accounts are managed as follows: 

By using the sub-account drop down box 102, the user may access and alter already existing 
sub-accounts. Once the user has selected a sub-account using drop down box 102, the service will 
permit access the sub-account information, recalling it from the database server 2. Each sub-account 
may be allowed to rate and schedule, track, or view (depending on the settings of check boxes 100, 
set by the user) reports for any set of locations in the database accessible by the user's master 
account. The user selects those locations for desired access and adds them using the add location 
button 104. The service then modifies the database to reflect the sub-accounts access to the location 
added. The user may also alter or delete locations from the sub-account using the modify location 
button 107 and the delete location button 108. By re-entering the PIN for the sub-account in PIN box 
101 the user may alter the PIN for an individual sub-account. The status of the sub-account may be 
changed or set using status radio button 99, and set to either subsidiary/affiliate or vendor/non- 
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affiliate. Once the user is done altering the sub-account, the user presses the save button 105, and 
the service updates the database to reflect the changes or additions made by the user. The reset 
button 106 permits the user to reset the page to a neutral setting. Once the user has finished, the user 
may redirect their browser to another page. 

The LTL rating process is described in the flowchart shown in Figure 17. The LTL rating 
process is managed by the service. Once the user has input the rating data, the user chooses to rate 
the service by clicking 'rate', as described above. The database server 2 first runs a query against 
the database of carriers providing service to the zip codes chosen by the user, or determines the 
serviceable carriers 109. The database server 2 then determines the base rate 110 for each carrier, 
which may be negotiated by the user's affiliation group or by the service. This step is performed for 
each serviceable carrier as determined above. The database server 2 then applies the appropriate 
carrier discount 111, again determined from the database information as appropriate for the user's 
affiliation group or as negotiated by the service. This step is again performed for each serviceable 
carrier. If the resulting charge for the carrier is below their minimum charge, the service will apply 
the minimum charge instead of the calculated charge at the apply minimum charge step 114. This 
step is also performed for each serviceable carrier. Finally, the system will apply the markup 
associated with the user or the user's affiliation group for each serviceable carrier at the apply 
markup step 1 15. The resulting carriers and rates will then be displayed to the user by the web server 
in the form of a drop down box, as shown above. 

It will be apparent to those of ordinary skill in the art that many changes and modifications 
could be made while remaining within the scope of the invention. It is intended to cover all such 
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equivalent methods or systems, and to limit the invention only as specifically delineated in the 
following claims. 

It is readily apparent that the claimed invention may be embodied in a number of manners. 
Though the disclosed embodiment, and the currently preferred embodiment, is a series of web pages 
5 run on a web server 1 and a database server 2, the invention could be a network-based program run 
over a distributed system, a set of web pages run on a single server or distributed server, or any other 
alternative which may be immediately apparent to one skilled in the art, and that advances in 
distributed networks may make possible embodiments which are not presently available without 
making substantial changes to the invention. 
1 o The above description is not intended to limit the meaning of the words used in the following 

claims that define the invention. Rather, it is contemplated that future modifications in structure, 
function or result will exist that are not substantial changes and that all such insubstantial changes 
in what is claimed are intended to be covered by the claims. 
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What is claimed is: 

1 . A computer based system for reducing errors in freight services and billing comprising: 

a) a server computer; 

b) a distributed network connected to the server computer; 

5 c) a user computer connected to the distributed network which can interact with 

the server computer; and 

d) a database on the server computer containing accessorial service information; 

e) programs or software for displaying accessorial services and requiring the user 
to address accessorial services offered and to select those accessorial services desired. 

10 2. The system of claim 1 wherein each accessorial service must be addressed 

individually. 

3. The system of claim 2 wherein the user is not permitted to complete the transaction 
until each service has been addressed. 

4. The system of claim 1 wherein after completion of the selection a summary of 
1 5 services selected is presented to the user. 

5. The system of claim 1 wherein after completion of the selection a summary of 
services selected and services rejected is presented. 

6. The system of claim 1 wherein the accessorial services are presented as a list. 
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7. The system of claim 6 wherein the user is not permitted to complete the transaction 
until at least one element of the list has been selected by the user, or no service has been 
affirmatively selected by the user. 

8. A computer based system for reducing errors in freight services and billing 
comprising: 

a) a server computer; 

b) a distributed network connected to the server computer; 

c) a user computer connected to the distributed network which can interact with 
the server computer; and 

d) a database on the server computer containing stored data comprising 
previously input user information; 

e) programs or software for reconciling new user input information with said 
stored data to reduce errors. 

9. The system of claim 8 wherein the user is prompted to re-input information if an 
inconsistency is found between the new user input and said stored data. 

1 0. The system of claim 8 wherein input zip code information is used to reconcile the new 
user input with said stored data. 

1 1 . The system of claim 8 wherein the user is prompted to select between the stored data 
and the new user input. 

12. The system of claim 8 wherein the user is provided an opportunity to select either the 
stored data or the new user input. 
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13. The system of claim 8 wherein the user is provided an opportunity to select either 
stored data or the new user input to edit as a further new user input. 

14. The system of claim 1 3 wherein said further new user input is reconciled against the 
stored data. 
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0 More Shipment to Scneduto- 




'■yfi Review \ 

Pi* < v v ^ invoice* ^ 




1-9 More Shipments to Schedule - 



Syrcm dynamically store* all available addresses for the 
shipment. Customer can sdd/use forfuUxe u*e 



System posts all additional services available for tne 
carrier cno&en ror tne shipment 



System dynamically stores all prod jcle far the cutttcmer 
Tor future use. 



Customer picks t*e ready deie and tima or the shipment 
Th'u ita-Tips on the Mirier pi=kup roqueit fax 



Oystornsr can choose to create wi invoice to wnd to 
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System eenerotea completed Invoio* for the customer lo 
use. We incorporated a Print Button tor the HTML paoe. 



-Confirm (NO)- 



AJ;or customer confirm* shipment setup, our internal 
system automatically fexw a pickup recast to the 
center terminal and e completed Bill 0 f Letfno to 
the shipper. 



System gorwrato* completed Bill of Lading for customer, 
W« incorporated a Print Button fcr the HTML page. 



LtKjifi - Micrbioft Internet Ftptorei • 



Access Code: f 
PIN: r 



i Submit' I I.ReBBt 



Association Member Benefits ^ 



ABC Company 
!585 Main Street 



11 



lAnytown ;KS 66202! 



(Click a menu item) 



Vt f L^F&le 7£ S c h e d u I e P i c k u p 



Invoice Inquiry 



Shipment Logs 



£iisto mi zed Repp r t s 



IS 
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Association Member Benefits * * 



Rate Your LTL Shipments 



5. 
6. 
7. 
8. 
9. 
10. 
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Origin Zip 


Dest. Zip 


Class 


1. 


66202 | 


55125 


70 


2. 


94544 | 


66202 


50 


3. 


94544 | 


l_85024 


I 70 | 


4. 


33124 


64111 


Multiple 



Total Wt. 



"3 



1251 



5230 



3212 



810 
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Member 


Carrier 


Price 


SCAC 


$185.03 


CFWY 


$713.18 


CFWY 


$431.64 


CRNT 


$165.86 


ODFL 
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Est. 
Transit 
(days) 

1 

3 
1 

2 



When you have completed rating all of your shipments and 
selected the shipments for pickup arrangement, click here. 



3S 

Arrange pickup 

^Yes r|\|o 
^Yes r|\io 
<~ Yes <?No 
^Jres r No 
rYes r No 
rYes r^o 
rYes rNo 
rYes rNo 
rYes TNo 
rYes rNo 
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Enter Multiple Shipment Information 



Origin Zip DestZip 
2. BB202 55125 



Class Wt(lbs) Enter classfts and 
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1 si 


1° I 


1 £i 
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product being shipped 
for this movement 



;?3 



S3 



a* •! 

: « i: 

i 
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Carrier SCAC: ODFL 

Origin Zip: 66202 
Destination Zip: 55125 

Total Weight: 1252 
Class: 100 

Your Freight Cost: $368.67 
Additional Fees: 4.00 
Total Cost: $368.67 
Est. Transit (days): 1 
Carrier Hame: 
Old Dominion FreiyM Line 



Association Member Benefits * M 

Schedule Your LTL Shipments 



H You are the j£j Shipper of this shipment, 
r Receiver 
r 3rd Party 



H\ A 




Carrier SCAC: ODPL 

Origin Zip: 66202 
Destination Zip: 55125 

TotaJ Weight: 1252 
Class: 100 

Your Freight Cost: &36S.67 
Additional Fees: $.00 
Total Cost: $368.67 
Est. Transit (days): 1 
Carrier Name: 
: Old Dominion Freight Line 



:inet Explorer 



DACK 



NEXT 



Association Member Benefits 



Schedule Your LTL Shipments 



C] Choose/Create receiving address information. Click Add. if you wish to add a 
new address. If your address is incorrect, please press.the Help Button or call 
freightquote at 1-888-595-5664. 




Shipment 1 of 1 

Carrier SCAC: ODFL 

Origin Zip: 66202 
Destination Zip: 55125 

Total WciQM: 1252 
Class: 100 

Your Freight Cost: $368.67 

Additional Pees: $17.50 

Total Cost: $386.17 

Est. Transit (days): 1 

Carrier Name: 
Old Dominion Freight Line 



unci Explorer 



Association Member Benefits ^ 



Schedule Your LTL Shipments 



n Choose all accessorial services required for this shipment. Extra charges 
may apply. An audit of this shipment must be done by freightquote that may 
change the amount posted to you. 



~irr 
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OACK NEXT 



Arrival Notification $17.50 
M Construction Site 
j Inside Delivery 
M Liftgate Service 
M Reconsignment 
4 Redelivery 
M Residential Deleivery 
M Residential Pickup 
0 Saturday Delivery 



"^Shipment 1 of 3 

Carrier SCAC: ODFL 

Origin Zip: 66202 
. Destination Zip: 55125 

Total Weight; 1252 
Class: 100 
Your Freight Cost: $3ti8;67 
Additional Tees: S.00 
Total Cost: $368.67 
Est. Transit (days): 1 

Carrier Name: 
Old Dominion FrcitjhrLine 



Association Member Benefits 

Schedule Your LTL Shipments 



□ Choose or Create Product Description for each producUieing shipped for this 
movement. A NMFC# is required for each product. Choose (Add a Product) from 
the Product Description drop down box if you wish entefpew product information. 



Product Description Class Weight 
100 1252 

SS 5b S? 



NMFCtf 



58 



HZMT 


PKG Type , 


[ r 


[Pellet |g 


Si 




Pellet 




Crate :| 






Box -J 






Roll zl 









M 



BACK 



NEXT 
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Shipment 1 of 3 

Carrier SCAC: OOFL 
Origin Zip: 66202 
Destination Zip: 55125 

Total Weight: 1252 
Class: 100 

Your Freight Cost: $368.67 

Additional Fees: $.00 

Total Cost: $368.67 

Est. Transit (days): 1 

j Carrier Name: 
. Old Dominion Freiyht Line 
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Schedule Your LTL Shipments 



0 Identify when your shipment Is ready for pickup from the carrier. 
Please allow the carrier 48 hours after the shipment ready date 
and time to pick-up. 



Schedule your pickup within 
the next 2 business days. 




Ready Time 

After M'fJfiFl 
Before ^fljjjgj^] 

please allow the carriers a 4 how 
window to pickup within. 



Fl<rL>(tC 



Shipment 1 of 3 

Carrier SCAC: ODFL 
Origin Zip: 66202 
Destination Zip: 55125 

Total Weight: 1252 
Class: 100 

Your Freight Cost: $368.67 

Additional Fees: $.00 

Total Cost: $368.67 

Est. Transit (days): 1 

Carrier Uamc: 
Old Dominion Freitjht Line 



rtnel Exploie 



BED 



Association Member Benefits 



an 



Schedule Your LTL Shipments 



0W1II you be invoicing another party for this shipment after you are billed from freightquote? 
If yes, this system can create your freight invoice. You can either include or exclude your 
member discounts to your customer. Please complete A, B and C. : 



□ 



□ 



□ 



BACK 



NEXT 
66 



Would you like to print an invoice of this shipment to send to another company? 
Or Ye* UNo 



Do you wish to pass on yaw memlier discounts to this company? 




Who is the company you will he invoicing at a later date? 

Company: 
Street Address: 

City. ST. Zip 

Phone: 
Contact Name: 
_'. Your Reference # 



3 Print Invoice - Microsoft Internet EKplomi 



Print your customer's invoice copy by clicking the Print Invoice 
button. 



Print invoice 



68 



INVOICE 



TO: 



Williams Companies 
500 E. 152nd Street 
New York, NY 21212 



FROM: 

ABC Company 
585 Main Street 

Anytown, KS 66202 

Ph: 9135558585 
Fax: 9135559000 



iL 



Invoice Summary 



BOL#: 10014 

Carrier: Old Dominion Freisht Line 



Invoice Amount: 
Invoice Date: 



S54P.47 
3/18/99 . 



Review the invoice. If invoice changes dack 
are needed, dick Back to go back and 
make corrections. 
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If the invoice is correct, print the invoice 
using the print button and click Next. 



t r. 



^3 Stail | fgj Microsoft Image Ccrr>pose: j SnagIt/32 



| EyMioo«>ftVoid-touVTgw..,| ^ heicMouote.com Micioso...| C]Pimt Invoice • Microt... |£5^:<D 8.56 PM 
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Association Member Benef its 



Press OK to complete this shipment and 
print Bill of Lading (BOL). 

1 If vol. are not the sender, please notify them regarding this movement and fax a 
' cop ^ the completed Bill of Lading to the sender. The sender must use our 

generated Bill of Lading (BOL) in order for you to receive accurate pnc.ng and 
shipment processing. 

2 The carrier will pick up your freight within 48 hours of the scheduled Ready Date 
' and Time. You do not need to contact the carrier for pickup. 

3 We will invoice you at the end of the month for this movement. If any freight 
Sation changes forthis movement additional or fees may be 
added to this movement's cost after shipment auditing (1 -4 weeks). 
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Use button below to print three copies of this Bill of Lading. Your driver 
must use this Bill of Lading to insure accurate shipment processing. 



BOL#: 10006 



ERO#: 



Shipper Name: 
Street Addrl; 
Street Addr2: 
Cny, ST. Zip: 



Shipper Information 

[ABC Company 



i Main Street 



||^W/n.KS 68202 



Bill Third Party To: 



FRE1GHTQUOTE, LLC 
10100 SANTA FE DR. 

surrE ido 

OVERLAND PARK, KS 66212 



Phone: §135556585 



Contact JJohri Smith j 



Bill Charges To: 

PREPAID / BILL THIRD PARTY 
ONLY 



Receiver Information 

Recewer Nam* j|ywiiams Dj^ijib^jon^^ZI 

Sue&t Addrl: j|S000 N. "Kentucky Avanug ^~ 

Street Addr2: ; J [loading dock) ~*~ 



„.CttY_ST. ^ip; jlsainl paul. MN 55125 



Special Instructions: 



1. Print Bill of Lading (BOL) by clicking here 

2. Give two copies to the driver. Keep one for 
your records. 

3. Thank you for using freightquate.com. 

Click here to continue 



:;PrintBOL 
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|lnv# 


Inv Date 


Due Date prior Bal 


New Charges Payments/Crdts Total Due 


123456 


2/28/1999 


3/20/1999 


0 


252.12 


0 


252.12 


145678 


3/31/1999 


4/20/1999 


252.12 


558.15 


252.12 


558.15 


156789 


4/30/1999 


5/20/1999 


558.15 


1020.60 


500.00 


1079.62* 


178922 


5/31/1999 


6/20/1999 


1079.62 


1150.50 


1079.62 


1150.50 


165678 [6/30/1999 


7/20/1999 


252.12 


558.15 


252.12 


558.15 


176789 [7/31/1999 


8/20/1999 


1079.62 


1150.50 


1079.62 


1150.50 



* Includes a 1.5% finance charge added to unpaid prior balance 
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Click on the column you wish to arrange your shipments by. Highlight the desired 
shipment and click Print BOL (Bill of Lading), or Print POD (Proof of Delivery). 



7? in 91 k>_ si &^ ..ft* 



BOL Number 


SCAC 


Status 


Picked UP 


Delivered Signed By 


Time | 


|1 234567800001 jAMER 


PENDING 


4/03/1999 . 






jl 234567800002 


ODFL 


PENDING 


4/04/1999 


1234567800003 


CFWY 


IN TRANSIT 


4/02/1999 


|1 234567800004 CFWY 


IN TRANSIT 


4/02/1999 


|1 234567800005 jAMER 


DELIVERED 3/15/1999 3/17/1999 J SMITH 


13:45 


jl 234567800006 DAFG 


DELIVERED 


3/02/1999 


3/05/1999 , R JOHNSON 


13:45 


zl 



Print BOL | Print POD | 
8H 3 £ 



Click oni the report you wish to run. Autorun Reports are 

highlighted in Blue (you will automatically receive these reports). 

Shipments To Be Shiprrterils Already Create Autorun 

Invoiced invoiced Reports 



Cost Report: 

To/From 
Specified 
Locations 



8<> 



Cost Report: 

ToiFram 
Specified 
Location 



3? 
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Tracking 
Report: 

Shipment 
Transit Status 



Tracking 
Report: 

Shipment 
Transit Status 



"70 




fx 



CREATE 
CUSTOM 
REPORT 



F |(,u|i"C 



is 



Run Cost Report 



Report 1: Zip Code Range 



Origin 



Destination 



u ^ 

WS&s§ 1^212 Jt o|Aix j 

Start Stop 
|l/l/1999__ : to |l/31/1999i! 



® Email ! ° ij s ^@abc-company.net ' 



C Fax 



to 



r 




87T 



Report Name; Billing Summary 
from: l-Jan-99 to 



Report on: 



Master Account 



31-Jan-99 



ABC Company 

123 South Main Street 

Overland Park, KS 66212 



Report Date: 3-May-99 



Report to: 



Master Account 



ABC Company 

123 South Main Street 

Overland Park, KS 66212 





BOU 


Ship Date Delivered 


Weight 


Cost 


1 


100001 


1/1/99 


1/4/99 


120 


$68.50 


2 


100002 


1/1/99 


1/4/99 


100 


$85.23 


3 


100003 


1/1/99 


1/4/99 


656 


$122.20 


4 


100004 


1/5/99 


1/8/99 


230 


$51.12 


5 


100005 


1/5/99 


1/8/99 


58 


$40.00 


6 


100006 


1/10/99 


1/14/99 


502 


$98.90 


7 


100007 


1/10/99 


1/14/99 


650 


$225.25 


8 


100008 


1/10/99 


1/15/99 


250 


$100.20 


9 


100009 


1/11/99 


1/15/99 


120 


$68.50 


10 


100010 


1/15/99 


1/19/99 


50 


$60.20 


11 


100011 


1/15/99 


1/23/99 


220 


$122.20 


12 


100012 


1/23/99 


1/25/99 


262 


$51.90 


13 


100013 


1/23/99 


1/26/99 


120 


$64.50 


14 


100014 


1/23/99 


1/26/99 


85 


$85.82 


15 


100015 


1/23/99 


1/29/99 


1252 


$321.01 



16 
17 
18 
19 
20 



Total Page I: 



Overall Total: 



$1,565.53 
$1,565.53 



Average: $104.37 
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Run Tracking Report 



i 



Report 1: Zip Code Range 

Origin Destination 



j|||^tp : i|| |66212 j to [55125 

Start Stop 



|H5n?9Lj to 1 1/31/1 999 j 



e Email to jj sm j t h(^c : conipai^.aet 



C Fax to [ 




Report Name: Transit Summary 
from: l-Jan-99 to 



Report Date: 6-May-99 



31-Jan-?9 



Report on: 



Affiliate Account 



ABC Company 

555 Williamsburg Ave 

Dayton, OH 55125 



Report to: 



Master Account 



ABC Company 

123 South Main Street 

Overland Park, KS 66212 





BOU 


SMpJDate 


Delivered 


WeiEht 


Transit Days 


1 


100001 


1/1/99 


1/4/99 


120 


1 


2 


100002 


1/1/99 


1/4/99 


100 
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DETAILED ACTION 
Drawings 

In view of the attached Notice of Draftsperson's Patent Drawing Review (PTO 948), and 
in view of revised USPTO policies and procedures regarding drawings, a proposed drawing 
correction or corrected drawings are required to reply to the Office action to avoid abandonment 
of the application. The objection to the drawings will not be held in abeyance. 

Claim Rejections - 35 USC § 112 

The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

Claims 1-3 and 6 are rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. 

As per claim 1, it is unclear from the claim language exactly how the claimed invention 
reduces errors in freight services and billing. The system is actually more directed to reducing 
user errors, since that is where the mistakes occur. The actual billing and services are correct in 
that they reflect accurately what the user has chosen. Any discrepancies are a result of user 
errors not system errors. Accordingly, the preamble of the claim should be amended to reflect 
this distinction. Claims 2, 3, and 6 are rejected since they depend from rejected claim 1 . 



Claim Rejections - 35 USC §103 
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The following is a quotation of 35 U.S.C 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

Claims 1-3 and 6 are rejected under 35 U.S.C. 103(a) as being unpatentable over Hunt et 
al. in view of Danford-Klein et al. (U.S. Patent 6,061,667) and Laverly. 

As per claim 1, Hunt et al. teaches a server computer 83 (including system processor 90); 
a distributed network 80 connected to the server; a user computer 106 connected to the network; 
a database (see column 5, line 25) on the server containing shipping information (see column 3, 
lines 7-23). Hunt et al. does not teach programs or software for displaying at least one 
accessorial service and requiring the user to address the accessorial service offered and to accept 
or decline the accessorial service. 

First, it is noted that the various types of accessorial services listed are all common and 
well known in the art, as described by Danford-Klein et al. (see Table 1, columns 17-19). 
Further, note that the system of claim 1 does not perform any of the accessorial services, it 
merely presents these as options to a customer that the customer must expressly accept of 
decline. Accordingly, the listed accessorial services are, in effect, nonfunctional descriptive 
material. As a result, the patentable distinction of the claim cannot rely on the type or title of 
service. The system would perform the same no matter what the title of the service was. The 
only difference a particular service type would yield would be what the customer would think or 
expect. This is not a structural distinction. Further, the reason why this is done, by itself, does 
not lend patentable weight. What matters is what is done, not why. Other motivations could 
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exist to do similar things for other services, e.g. to increase earnings for the merchant by making 
a customer specifically decline or accept an extended warranty or a maintenance plan or even 
accessories for the product purchased prior to checking out. 

Second, the notion of requiring a user to accept or decline an option is well known in the 
art of computer programming. Laverly, for example, teaches a system requiring user agreement 
before proceeding, and explicitly requiring the user to accept or decline the agreement (see page 
I, 5 th paragraph). The fact that the applicant applies this feature within the context of accessorial 
services does not render it patentable over the prior art. It would have been obvious to one of 
ordinary skill in the art at the time the invention was made to apply this accept/decline feature of 
Laverly to the system of Hunt et al. since the basic concept (i.e., requiring a user to accept or 
decline an agreement before proceeding) is well known in the art, and since applying this feature 
to the case of accessorial services is simply a specific application of requiring a user to accept or 
decline information. The accept/decline feature, even though applied by applicant to a different 
type of information, does not in itself render the claim patentable over the prior art. Also, the 
fact that it is being applied in order to reduce errors in freight services and billing does not lend 
patentable weight, since this simply pertains to why the feature is applied, not what is actually 
done. 

As per claims 2 and 6, official notice is taken that addressing information individually or 
in a list are both common in the art of GUI programming and would have been obvious design 
choices are to how to present the agreement information. 

As per claim 3, Laverly further teaches the user not being permitted to proceed until the 
agreement has been addressed (see page 1, 5 th paragraph). 



Application/Control Number: 09/557,822 
Art Unit: 3744 



Page 5 



Remarks 

The examiner notes that the above rejections are in contrast with the agreement reached 
between the Examiner and the Applicant during the interview conducted on 6 November 2001. 
However, further examination (particularly related to the issue of requiring a user to accept or 
decline on-line information) necessitated this rejection. In view of the previous agreement, the 
Examiner wishes to apologize to the Applicant for any inconvenience that this new rejection 
might cause. 

Conclusion 

The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

Menzies teaches a system wherein a consumer chooses or declines an extended warranty. 

Sonderegger (U.S. Patent 5,893,1 18); Peters et al. (U.S. Patent 5,893,098); Brandt et al. 
(U.S. Patent 5,892,905); Godin et al. (U.S. Patent 5,890,138); Koreeda (U.S. Patent 5,890,137); 
Weber (U.S. Patent 5,889,863); Vanechanos, Jr. (U.S. Patent 5,884,309); Cook (U.S. Patent 
5,860,068); Cohen et al. (U.S. Patent 5,847,957); Montulli (U.S. Patent 5,826,242); Ogram(U.S. 
Patent 5,822,737); Teper et al. (U.S. Patent 5,815,665); Weber (U.S. Patent 5,787,400); 
Wesinger, Jr. et al. (U.S. Patent 5,778,367); Storey (U.S. Patent 5,774,870); Levine et al. (U.S. 
Patent 5,745,681); Chelliah et al. (U.S. Patent 5,710,887); Anderson et al. (U.S. Patent 
5,706,442); Hogan (U.S. Patent 5,699,528); Shavit et al. (U.S. Patent 4,799,156) were all 
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ABSTRACT: More and more Web site publishers are attempting to set their own 
rules by imposing "terms and conditions" on people visiting their sites. 
Many webmasters are putting hypertext READ THIS notices on their home 
pages. These postings link to terms and conditions that purport to govern 
users of the web site. Tips for the web site publisher on how to 
effectively draft terms are provided. 

TEXT: The World Wide Web is the wild frontier of commerce, and the law has 
not caught up with all the activity on the open range. Web sites offer 
users tremendous resources: database information, chat rooms, bulletin 
boards, free software, and entertainment. Universal rules for the use of 
these resources, however, do not yet exist. Without clear standards of 
behavior, users could start the chat room equivalent of a saloon fight, or 
make off like rustlers with a Web site's intellectual property. 

More and more Web site publishers are attempting to set their own rules by 
imposing "terms and conditions" on people visiting their sites. Like a 
sheriff posting a warning at the edge of town, many Webmasters are putting 
hypertext READ THIS notices on their home pages. These postings link to 
terms and conditions that purport to govern users of the Web site. Even 
without a six-shooter and a tin star, the following tips will provide some 
ammunition for drafting terms that can keep the peace on a Web site: 

Make the terms and conditions conspicuous. Merely giving clear notice of 
what behavior is expected will bring most users into line. A link to the 
terms of use, or the terms themselves, should be clearly and prominently 
labeled on the home page. 

Require user agreement before proceeding. Common ways to get a user 

to agree to the terms of use include a button saying "I Agree " or a 

dialog box in which the user must type in his or her name. The user 
should also have the explicit option to reject the terms and leave the 
. Web site, such as a button saying, "I Do Not Agree . " At minimum, the 

home page of the Web site should clearly state that, proceeding to use the 

site constitutes agreement to the terms and conditions conspicuously 

shown to the user • 

Make disclaimers regarding content. When appropriate, the terms of use 
should include disclaimers regarding the content of the site. If the Web 
site has an unmonitored bulletin board service available for users, the 
terms should specifically disclaim any responsibility for or review of user 
nosines on the bulletin board. 

Include a license for content If the Web publisher wants to restrict 
copying, redistribution, or other use of the content on the Web site, the 
terms of use should include a license to that content. . 

Note appropriate guidelines for bulletin boards and chat. Terms of use 
should forbid the user from uploading anything that is obscene, infringes 
copyright, defames, or otherwise injures any person or entity. The terms 
and conditions should not imply, however, that the Web publisher will 
monitor the site, if that is not the case. In some situations, the user may 
be required to indemnify the Web publisher against any claim arising out of 
the user s breach of the site's guidelines. 



Invite correction reqr ~ts . The terms may extend an of >r to remove-upon 
request-any infringing, ,famatory, or other objectionab material, if the 
requesting user can adequately explain the nature of his or her objection. 

Obtain a license from users. If the Web site publishes any user content on 
bulletin boards, chat rooms, or in any other form, each user should be 
required to grant a commensurate license to the Web publisher. 

State a choice of law, jurisdiction, and venue. While the Web publisher may 
be located in Dodge City, a user may be located in Beijing. The terms and 
conditions should establish which jurisdiction's law will apply to their 
enforcement, and which jurisdiction's courts will have authority to judge 
any disputes. 

Reserve the right to change and terminate. The terms and conditions should 
allow the Web publisher to change the terms from time to time by posting 
the changes on the Web site. Unless the user is paying for a defined period 
of access to a site, the Web publisher should reserve the right to 
terminate the agreement and the user's right to access the Web site under 
the terms and conditions, without notice. 

While such terms and conditions may not actually keep all the bad guys off 
the Web site, they can at least allow the Web publisher to show it took 
reasonable steps to dissuade bad behavior. The terms may even provide the 
basis for a lawsuit against outlaws who have agreed to the terms prior to 
using the Web site. In any event, clear and conspicuous terms of use are an 
important step to finding "happy trails" on the Web. 

Author Affiliation: 

Liam IL Lavery is an attorney in the Seattle office of Preston Gates & 
Ellis LLP, with a practice focusing on intellectual property and online 
transactions. 
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ABSTRACT 



The invention is a method for brokering carrier capacity. The 
method comprises a dual path; one path that allows entry 
into a data processing system of available carrier capacity 
which is comprised of a list of parameters which define that 
capacity, and the second path which allows access to that 
capacity. Each entry point to the system has data entry 
means for either entering carrier capacity or entering a 
request for available routes, or both. Available capacity 
eotries are confirmed, saved in a transportation database, and 
assigned a pre-transaction code. Path two involves entering 
a request for available capacity by defining a requested route 
based upon a list of parameters. The system compares 
available capacity with the requested route to determine 
whether or not a match exists. The system operator selects 
an appropriate matched entry which must then be confirmed. 
Upon confirmation, selected matches are saved to a trans- 
action database and assigned a transaction code. If no match 
is determined, then the requested route data is saved to a 
request database. A request database locator program is then 
activated for the purpose of querying the transportation 
database at prc-detcrmined intervals to determine if a match- 
ing capacity has been subsequently entered. If a matching 
capacity has been subsequently entered, then a prompt is 
sent to the requesting site indicating that a match has been 
found and that confirmation is required; otherwise, the 
request database locator program will continue to query the 
transportation database until the routine is terminated. 

21 Claims, 8 Drawing Sheets 
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METHOD AND SYSTEM FOR BROKERING FUNCTIONS, issued Dec. 15, 1987 to Sharpc el al., and in 

EXCESS CARRIER CAPACITY U.S. Pat. No. 5,222,018, also for a SYSTEM FOR CEN- 

TRALIZED PROCESSING OF ACCOUNTING AND PAY- 
MENT FUNCTIONS, and issued Jun. 22, 1993 to Sharpe et 
RELATED APPLICATION 5 al., these systems do not provide a means or method for 

determining or defining carrier space; these systems merely 
Reference is made to application Scr. No. 08/572,769 pravide a revenue or cost value which can then be used for 
(Attorney Docket No. E-M3), entitled METHOD AND purposcs . 
SYSTEM FOR LISTING, BROKERING, AND ^ ^ . , . t . 

EXCHANGING CARRIER CAPACITY, signed to the M . Combining earner space defimtton together wrticwml- 
c i_ ' .- .■ • ^.l • p, k ion? 10 m& for that space was accomplished in part by the SABRE 
assignee of tins apphcaUon and filed on Dec. 15, 1995, now ^ ^ ^ ^ ^ 

Ui. Pat. no. 5,/Z4,^. developed by American Airlines. Inc. of Dallas/Ft. Wbrtb 

BACKGROUND OF THE INVENTION Airport, Tex. The above named systems, and their industry 

counterparts, allow travel agencies and carriers to identify 

The ability of shippers to get parcels from the loading is S p ace available by scat or by room, book reservations, and 

dock to the final destination in shorter time spans and at less tnen pro duce accounting data so that revenue debits and 

cost has increased in recent years. The growth of the credits can be booked automatically or manually for a 

overnight carriers, and the consistency of the two and three variety of report types, and then eventually billed if neces- 

day delivery carriers has created vast fleets of vehicles sarv 

representing each of the many transportation modes. 20 ^ presen | j nvcm ion is an improvement over reservation 

The growth of shipping demand has fueled the drive for systems such as SABRE or ADS because the ability to define 

efficiencies that each of the carriers has been developing. excess carrier capacity by specific size is more flexible and 

Technological advances and better methods of doing busi- more precise then the ability to define reserved or booked 

ness have in turn spurred greater demand for carrier services. space as performed in the reservation systems. Additionally, 

The net result is that the volume of parcels being shipped has 25 rc q UCSts f or cxccss space are continually, and automatically, 

continued to spiral upward. matched against available space until a match is found or 

Systems and methods have been proposed to more effi- until real-time makes a match prohibitive, as when the actual 

cicnlly handle the increased volume of parcels and the date arid time (real-lime) is later than the date and time thai 

proliferation of carrier services that are available. Carriers a particular space was available. Further, the system user has 

have introduced systems and methods that are targeted to 30 the ability to select the transport mode in determining 

that carrier only. Shippers have looked for systems that request parameters; the ability of the reservation systems to 

provide them with a means to rate or service shop. The provide mixed modal or alternative transport mode selection 

object of all of these systems has been to get a parcel on a is limited at best. 

vehicle for movement from point A to point B. ^ Therefore, an object of the present invention is to provide 

Carrier Management Systems such as that described in additional revenue or additional cost savings by creating a 

U.S. Pat. No. 5,040,1.32, SYSTEM FOR PREPARING method of notifying shippers that a carrier has excess 

SHIPPING DOCUMENTS, issued Aug. 13, L991 to Schu- capacity. In order to interest shippers in utilizing the avail- 

richt et al., are well known to the art. One such system is the able space, carriers can offer the space at a discount or at 

E900 Carrier Management System, developed and marketed ^ no-charge, the benefit obtained from "no-charge" space 

by the assignee of the present application. The E900 gen- being the goodwill associated with such offerings. The latter 

erally includes as peripheral elements: a microprocessor; could be reserved for special customers who achieve certain 

keyboard; monitor; platform scale; printer; and possibly a efficiencies during a qualifying period. The promotional 

scanner. The E900 system automatically prepares docu- opportunities are extensive. 

ments for shipping articles to any desired number of differ- 4J a further object of the present invention is to provide a 

cnt receivers by aoy selected carrier or mode. method thai can be utilized internally by a company to 

The ability of carriers to respond to shipper needs is based maximize its own efficiency. Many companies utilize inter- 
on the carrier's capacity. Carrier capacity is the space that is nal fleets of trucks or other vehicles to move product, 
available at any given time in the vehicle representing the inventory, or parcels within the company or within a tightly 
carrier's mode of transport. For every shipment that leaves so controlled network. The present invention would provide an 
the dock of a shipper bound for a particular destination, a easy method of locating available carrier capacity within the 
carrier makes available a mode of transportation. Each mode internal system so that time schedules could be more easily 
of transportation has its unique vehicle for transport: freight adhered to and the cost of utilizing outside carriers could be 
cars via rail; containers via ship; cubic inches via truck; etc. reduced. 

More often than not, the vehicle utilized by the carrier has 55 SUMMARY OF THE INVENTION 
"excess capacity." That is, the maximum available space in 

the vehicle is not fully utilized for the movement of pack- According to the invention, the object is achieved and the 

ages or parcels: at takeoff, the plane may have a few cubic disadvantages of the prior art are overcome by a method for 

feet of space available for shipping; at rollout, the freight brokering carrier capacity that provides flexibility to the 

train may have some available container space; or, at final «j users as well as the ability to be used within the internal 

pick-up, the truck may have some available space. Excess environment of one carrier or within a network of several 

capacity, therefore, represents revenue or opportunity lost to carriers. Brokering, as used herein, refers to a system that 

the carrier. acts as an intermediary between the shipper/user of carrier 

While accounting for carrier space revenue/cosls can be space and the carrier that has listed the space, 

determined in detail by systems such as that described in 65 The method comprises a number of steps. These steps 

U.S. Pal. No. 4,713,761, SYSTEM FOR CENTRALIZED occur over a dual path; one path that allows entry of 

PROCESSING OF ACCOUNTING AND PAYMENT available carrier capacity, and the second path which allows 
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access to [bat available capacity. The method employs a data 
processing system, with a real-time clock, supporting an 
application which embodies the method. There are at least 
Jwo entry points into the system. Each entry point has a real 
time clock as well as data entry means for entering either 5 
carrier capacity to the system or entering a request for 
available routes into the system, or both. 

Path one involves determining that carrier capacity is to 
be entered into the application, and then actually making 
such an entry. Entry data is comprised of a list of parameters 10 
which may include: amount of space available, destination; 
dates and times; rates; and mode of transport. Mode of 
transport would include, at least: air; ground; ship; rail; 
and/or mixed modal. Mixed modal is defined as the use of 
two or more modes of transport within a single route. The 
entry is then confirmed, saved in a transportation database, 1 
and assigned a pre-transaction code. 

Path two involves entering a request for available capacity 
into the system by defining a requested route. The requested 
route is defined by request data which is comprised of a list 
of parameters which may include: amount of space required, 20 
destination; dales and times; rates; and mode of transport. 
The fewer parameters that are entered, the greater the scope 
of the search. 

The system utilizes data processing means for determin- 
ing whether a match can be found between the request for 25 
available capacity and what has actually been entered into 
the transportation database. The system operator making the 
request for carrier capacity is provided with means for 
displaying the request made as well as displaying the located 
matched entries; the display means being preferably a moni- jq 
tor or a printer, or both, operatively connected to the data 
processing system. The operator can then select an appro- 
priate matched entry from among those displayed. The 
selection must then be confirmed. Upon confirmation, the 
selected matched entry is saved to a transaction database and 3S 
assigned a transaction code. The assignment of a transaction 
code can then be the initiating step in preparing a bill for 
services or generating a transaction report. 

Within path two of the method, there exists the possibility 
that no match will be found between what is available and 
what has been requested. If a null response is received when 
the requested route is compared with the listing of available 
capacity entered into the transportation database, (hen the 
requested route data is saved to a request database. 

A request database locator program is activated within the 
data processing system for the purpose of querying the 45 
transportation database at pre-determined time intervals to 
determine if a matching route selection has been entered into 
the transportation database subsequent to the initial request. 
If a matching route selection has been entered into the 
transportation database, then a prompt is sent to a display *° 
device at the location where the route request was made; the 
prompt indicating that a match has been found and that the 
system operator should enter the application to confirm the 
match. 

If, however, a matching route selection has not been 55 
entered into the transportation database, then the request 
database locator program will continue to query the trans- 
portation database at pre-determined time intervals until 
either the date and time of the requested route has exceeded 
the dale and lime on the real time clock of the data 60 
processing system, or until the query is terminated by the 
system operator. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 A is a block diagram of an embodiment of a system 65 
having a centralized database that can utilize the subject 
method as disclosed. 
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FIG. IB is a block diagram of an alternative embodiment 
of a system having point to point communication that can 
utilize the subject method as disclosed. 

FIG. 1C is a block diagram of an alternative embodiment 
of a system having multi-node interface that can utilize the 
subject method as disclosed. 

FIG. 2 is a flow chart of the initialization and entry into 
the two main paths of the method flow. 

FIG. 3Ais a flowchart of the method path whereby excess 
carrier capacity may be entered into the system for use. 

FIG. 3B is a flowchart of the method path whereby a 
system user can reserve space for use that has been entered 
into the system by a carrier. 

FIG. 3C is a continuation of the flowchart of the method 
path of FIG. 3B whereby a system user can reserve space for 
use that has been entered into the system by a carrier. 

FIG. 3D is a continuation of the flowchart of the method 
paih of FIG. 3C whereby a system user can reserve space for 
use that has been entered into the system by a carrier. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

Turning to FIG. 1A, there is depicted an embodiment of 
a system that employs the invention method. 

System 10 is comprised of subsystems 8 and 9. Subsystem 
8 represents an input/output point at a carrier or shipper site 
that is porting data to centralized database 50 which can be 
administered by the carrier, shipper, or a third party. Sub- 
system 8 further comprises: microprocessor 12, for process- 
ing data entered by the system operator, has a real-time clock 
used for determining when the actual date and time has 
passed, or is about to pass, the time of performance for the 
carrier space listed or requested; microprocessor 12 is opera- 
tively connected to monitor 14 where the system operator 
can view entries made to the system, matches available, or 
receive notification of a match; keyboard 16, which is used 
to make data entries to the system, is connected to micro- 
processor 12 by interface cable 20; modem 18, which can 
transmit or receive data entries or records to or from 
database 50, is connected to microprocessor 12 by interface 
cable 22; and, modem 18 which is further connected to 
database 50 by interface cable 24. 

Subsystem 9 represents an iaput/output point at a carrier 
or shipper site that is porting data to centralized database 50 
which can be administered by the carrier, shipper, or a third 
party. Subsystem 9 further comprises: microprocessor 30 for 
processing data entered by the system operator; micropro- 
cessor 30 is operatively connected to monitor 32 where the 
system operator can view entries made to the system, view 
matches available, or receive notification of a match; key- 
board 34, which is used to make data entries to the system, 
is connected to microprocessor 30 by interface cable 38; 
modem 36, which can transmit or receive data entries or 
records lo or from database 50, is connected to micropro- 
cessor 30 by interface cable 40; and, modem 36 which is 
further connected to database 50 by interface cable 42. 

In an alternative embodiment, modem 18 and/or modem 
36 can be connected lo database 50 by telephone lines which 
may further comprise: radio frequency (RF), multichannel 
(MUX), satellite, microwave, or similar links. 

Turning to FIG. IB, there is depicted an embodiment of 
a system that might employ the invention method. Sysiem 
45 is comprised of subsystems 43 and 44 and represents a 
direct point to poiol system of a type that might be used in 
an intracompany environment where the database does not 
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have to be separated out from the input/output points. It in FIG. 3A. If, however, the response to the query at step 152 
should be noted that this configuration could be altered to is "NO," then the method advances along path D to step 200 
accommodate more than two subsystems; an example is which is shown in FIG. 3B. 

found in FIG. 1C. Turning to FIG. 3A, path A enters at step 160 where the 

Subsystem 43 further comprises: microprocessor 47 5 ro utc start point and linish point are entered. It is at this step 

operativcly connected to monitor 49 for viewing record mat intermediate points, if any, can be identified. The 

entries or other data; keyboard 51, for entering data to the preferred method of entry is by using start and destination 

system, is connected to microprocessor 47 by interface cable posUl CQfks ^ cotIc io ^ u mtC( i States); these are well 

55; modem 53, for transmitting data, is connected to micro- known in the art. The degree of accuracy required in 

processor 47 by interface cable 57; and modem 53 further lQ es[ablishing ick . up and delivery points can be adjusted 

connected to modem 71 by interface cable 77. Subsystem 44 accordi t0 the (ype of postal code accep ted by the system, 

further comprises: microprocessor 65 operatively connected 6 . iy /, r \ ' 

to monitor 67; keyboard 69 connected to microprocessor 65 . For instance, in the United States, the eleme nts of a postal 

by interface cable 73; modem 71 connected to micropro- ™P code consist of four parts; these are: (1) the zip code, 

cessor 65 by interface cable 75; and. modem 71 further which consists of 5 digits and refers to geographic area or 

connected to modem 53 by interface cable 77. 15 zone; (ii) the "Zip+4" further breaks down a zip code region 

In an alternative embodiment, modem 53 and/or modem into smaller sub-regions, this code consists of four digits 

71 can be connected to each other by telephone lines which added to the base zip code; (in) "delivery point digits" which 

may further comprise: radio frequency (RF), multichannel consist of two additional digits thai further break down a 

(MUX), satellite, microwave, or similar links. Zip+4 so that the carrier can more accurately pin point an 

Turning to FIG. 1C, there is depicted an embodiment of 20 «act location; and. (iv) a check sum digit; the check sum 

a system that might employ the invention method. System digit would not be reqmred in the present uivention. In the 

80 is comprised of subsystems S3, 85, and 87 and represents mailing services environment, the delivery point d.gHs are 

a network of direct point to point systems of a type that abstracted from the street line of the address using the 

might be used in an intracorcpany environment, or in a approved algorithm of the postal service; either the :U.S.P.S. 

I shared network environment. The database could reside in J algorithm or a proprietary algorithm could be used, 

any of the three subsystems 83, 85, or 87 or could be located After entry of the route start point and finish point at step 

in each of the subsystems when in an environment where the 160, the method advances to step 162 where the method 

database does not have to be separated out from the input/ queries as to whether or not the entry at step 160 was correct, 

output points, it should be noted that this configuration does If the response to the query is "NO." then the method returns 

not have to be limited to only three subsystems; additional to path A for re-entry to step 160. If, however, the response 

subsystems could be added. to 'he query at step 162 is "YES," then the method advances 

I Subsystem 83 further comprises: microprocessor 90, for to step 164 where the start and end dates and times of the 

processing system data, operativcly connected to monitor 92 ro"«e arc entered into the system. 

I for displaying data; keyboard 94, for entering data, con- 35 After entry of the route start and end dates and times at 

nected to microprocessor 90 by interface cable 98; modem step 164, the method advances to step 166 where the method 

96, for communicating data, connected to microprocessor 90 queries as to whether or not the entry at step 164 was correct, 

by interface cable 100; modem 96 connected to modem 112 If the response to the query is "NO," then the method returns 

by interface cable 138; and, modem 96 further connected to to step 164 for re-entry of the appropriate data. If, however, 

modem 130 by interface cable 136. ^ the response to the query at step 166 is "YES," then the 

Subsystem 85 further comprises: microprocessor 124, for method advances to step 168 where the mode of transport 

processing data, operatively connected to monitor 126 for (ie., sea, truck, rail, air, mixed modal) and the amount or 

displaying data; keyboard 128, for entering data, connected type of space available arc entered into the system, 

to microprocessor 124 by interface cable 132; modem 130, After entry of the mode of transport and the amount of 

for communicating data, connected to microprocessor 124 45 available space at step 168, the method advances to step 170 

by interface cable 134; modem 130 connected to modem 112 where the method queries as to whether or not the entry at 

by interface cable 118; and, modem 130 further connected to step 168 was correct. If the response to the query is "NO," 

modem 96 by interface cable 136. Additionally, subsystem then the method returns to step 168 for re-entry of the 

87 further comprises: microprocessor 106 operatively con- appropriate data. If, however, the response to the query at 

nected to monitor 108; keyboard 110 connected to micro- 50 step 170 is "YES," then the method advances to step 172 

processor 106 by interface cable 114; modem 112 connected where the rates and applicable charges are entered into the 

to microprocessor 106 by interface cable 116; modem 112 system. 

connected to modem 130 by interface cable 118; and, After entry of the rates at step 172, the method advances 

modem 112 further connected to modem 96 by interface j 0 S | C p 174 where the method queries as to whether or not 

cable 138, 55 the entry at step 172 was correct. If the respoasc to the query 

In an alternative embodiment, modem 96 and/or modem is "NO," then the method returns to step 172 for re-entry of 

112 and/or modem 130 can be connected to each other by the appropriate data. If, however, the response to the query 

telephone lines which may further comprise: radio fre- at step 174 is "YES," then the method advances to step 176 

quency (RF). multichannel (MUX), satellite, microwave, or where the entered routes and their corresponding rates are 

similar links. 60 displayed back to the system operator on monitor 14 or 

Turning to FIG. 2, there is depicted a flowchart of the alternatively on a printer, or both on a monitor and a printer, 

entry into the system application. The application is initial- After display of the routes and rates at step 176, the 

ized at step 150 and then advances to step 152. At step 152, method advances to step 178 where the method queries as to 

the system queries the system operator as to whether or not whether or not the entry displayed at step 176 was correct, 

the system operator is entering excess carrier capacity. 65 If the response to the query is "NO,* then the method returns 

If the response 10 the query at step 152 is "YES," then the to step 172 for re-entry of the appropriate data. If, however, 

method advances along path A to step 160 which is shown the response to the query at step 178 is "YES," then the 
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method advances to a query at step 180. At step 180, the response lo the query is "YES," then the method advances 

method queries as to whether or not to confirm the entry to step 214 where the matchmg route, or routes, is/arc 

displayed at step 176. If the response to the query is "NO,** displayed. If, however, the response to the query at step 212 

then the method advances to step 182 where the method is "NO," then the system advances to step 216 and displays 

further queries as lo whether or not the application is to be 5 "Route Not Available/* 

exited. If the response to the query at step 182 is "NO ," then From step 216 the method advances to step 222 and 

the method returns lo path A to re-enter at step 160. If, queries as to whether or not the requested carrier capacity 

however, the response to the query at step 182 is "YES," parameters should be saved until carrier capacity is made 

then the method advances to step 188 where the application available or until the real lime clock of the system has 

is exited. Returning to step 180, if the response to the query 10 advanced beyond the requested date and time parameters. If 

is "YES," then at step 184 the entered route and appropriate the response to the query at step 222 is "NO," then the 

rates are saved to the transportation database as available method advances to step 223 and queries as to whether or 

carrier capacity and are assigned a pre-transaction code. hot to exit the program. If the response lo the query at step 

From step 184, the method advances to a query al step 223 is "NO," then the method advances to path B where it 

186 At step 186, the method queries" as to whether or not « re-enters at step 200. If, however, the response to the query 

another entry is required. If the response to the query is at step 223 is "YES," then the method advances along path 

"YES," then the method advances to path A and re-enters at F to FIG. 3D where it enters al step 256. In looking back to 

step 160. If, however, the response to the query at step 186 step 222, if the response to the query is "YES," then the 

is "NO," then the method advances to step 188 and exits the method advances along path C to FIG. 3C where it enters at 

application. 20 step 224. 

The pre-transaction codeserves the purpose of identifying Returning to step 214, from the displayed list of available 

the available carrier capacity which has been placed in the routes, the system operator can scroll up or down the list and 

transportation database at step 184; the code, and a descrip- select an appropriate route by highlighting the entry and 

tion of the carrier capacity, will be displayed to a system entering the selection al step 218. Also entering at step 218 

operator when selection of available space is required, and 25 is path G which originated at step 242 of FIG. 3C. From step 

can be further used for identification io preparing reports and 218, the method advances to a query at step 220 which asks 

in the records necessary for regulated industries or transac- whether or not the entry selected at step 218 was the correct 

tions. Neither a discussion nor description of the reports entry. If the response to the query is "YES," then the method 

required by the carrier industry or regulating agencies are advances along path D to FIG. 3D where it enters at step 

advanced within this application as they are not required for 30 244. If the response to the query at step 220 is "NO " then 

an understanding of the subject invention. the method returns to enter the flow just after step 214 and 

Turning to FIG. 3B, the flow of path B as it enters from prior to step 218. 

FIG. 2 can be seen. Path B enters at step 200 where the start Turning lo FIG. 3C, the method enters at step 224 from 

point and end point of a requested route (requested capacity) path C which had originated at step 222. 

arc entered. Additionally, from FIG. 3D, path E enters at step At step 224, it is determined that the carrier capacity 

200 as well. request be saved and al step 226 the request parameters are 

Al step 200, the start and end points for the requested saved to the request database. From step 226, the method 

route are entered by: street; city; zone; state/province/ advances to step 228 and activates the request database 

prefecture; country; and/or postal code. From step 200, the ^ (RDB) locator program. 

method advances to a query at step 202 which asks if the The purpose of the RDB locator program is to query the 

entry made at step 200 is correct. If the response to the query transportation database at regular intervals that can be 

is "NO," then the method returns to path B and rc -enters at programmed at system set-up so as to locate available carrier 

step 200. If, however, the response to the query at step 202 capacity that may be entered in the system after the initial 

is "YES," then the method advances to step 204. 45 capacity request is made. The RDB locator program takes 

Al step 204, the ship date and time and the delivery dale the carrier capacity request parameters and asks the trans- 

and time for the route are entered; it is possible, at this point. portation database if a suitable match has been entered. The 

to enter ranges for dale and lime so as to broaden the RDB locator program will continue to query the transpor- 

database search for a match. From step 204, the system tation database until it is requested through a pull down 

advances to a query at step 206. The query at step 206 asks 50 menu that the RDB locator program terminate the query, or 

whether or nor the entry made at step 204 is correct. If the when the system's real time clock hasexceeded the time and 

response to the query is "NO," then the method returns to date parameters of the carrier capacity request. 

204 where the proper data can be entered. If, however, the Once the RDB locator program is activated at step 228, 

response to the query at step 206 is "YES," then the method the method advances to step 230 and begins querying the 

advances to step 208. 55 transportation database at regular intervals for a possible 

At step 204, the desired space dimensions for the route are match. If a match is found, the method advances to step 232 

entered, and then Ihc method advances to a query at step where the match is verified; the method then advances to 

210. The query at step 210 asks whether or nor the entry step 234 where the RDB locator program signals the system 

made al step 208 is correct. If the response to the query is operator that a match has been located. The RDB locator 

"NO," then the method returns to 208 where the proper data 60 program will continue to signal the system operator as long 

can be entered. IE, however, the response to the query at step as the match remains or until the system operator either 

210 is "YES," theo the method advances to slep 212. selects or discards the match. 

At step 212, the system queries itself as to whether or not From step 234, the method advances to step 236 where the 

the requested route entered is available. To accomplish the method continues lo check at regular intervals that the malch 

query, the system takes the parameters entered al steps 200, 65 still exists. The purpose of the continual malch check is to 

204, and 208 and compares them to the parameters stored in recognize that other carrier capacity requests may be enter- 

the transportation database as carrier capacity. If the ing the system from other entry points and, (hat the system 
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operator may not be able to respond to the match notification 
in a timely manner. From step 236, the method advances to 
step 238 and queries as to whether or not the match still 
remains. If the response to the query is "NO," then the 
method re-enters at step 226; otherwise, if the response to 5 
the query is "YES " then the method advances to step 240. 

Step 240 queries as to whether or not a match is still 
required. If the respoose to the query is "NO," then the 
method advances to path F which enters at step 254 in FIG. 
3D. If, however, the response to the query at step 240 is 10 
"YES," then the method advances to step 242 where the 
system operator selects the match. After selection of the 
offered match, the method advances along path G to re-enter 
at step 212 in FIG. 3B. 

Turaiog to FIG. 3D, the method enters at step 244 from 15 
path D which had originated at step 214 and, at step 256 
from path F which had originated at step 220. 

From path D, the method advances to step 244 where the 
selected route and rates are displayed. The method then ^ 
advances to step 246 and queries as to whether or not the 
entry displayed at step 244 is to be confirmed. If the response 
to the query is "NO," then the method advances to a query 
at step 248 which asks if the application is to be exited. If 
the response to the query at step 248 is "NO," then the 
method advances along path E to re-enter at step 200 in FIG. 
3B. If. however, ibe response to the query at step 248 is 
"YES," then the method advances to step 249 and exits the 
application. ~ 

Returning to step 246, if the response to the query is ^ 
"YES," then the method advances to step 250 where the 
selection is saved to the transaction database and assigned a 
transaction code. The transaction database will serve as the 
data base from which a number of different reports and 
documentation can be generated for the appropriate carrier 35 
needs and regulatory authorities. In saving to the transaction 
database, at step 252, the system decrements the selected 
capacity from the available capacity stored in the transpor- 
tation database. From step 252, the method advances to step 
254. m 

At step 254, the method queries as to whether or not 
another selection is required. If the response to the query is 
"YES," then the method advances along path E to enter at 
step 200 in FIG. 3B. It, however, the response to the query 
at step 254 is "NO," Ibeo the method advances to step 256 45 
and queries as to whether or not the system operator wishes 
to print any of the reports that are available. If the response 
to the query is "NO," then the method advances to a query 
at step 260. If, however, the response to the query at step 256 
is "YES," then the method advances to step 258 where the 50 
system operator can select one or more reports to be printed. 
From step 258 the method advances to the query at step 260. 

The method queries at step 260 as to whether or not the 
system operator wants to select another activity. If the 
response to the query is "NO," then the method advances to 55 
step 264 and exits the application. If, however, the response 
to the query at step 260 is "YES," then the method advances 
to step 262 where the operator can select a next activity from 
a "RETURN TO" menu. The "RETURN TO" menu allows 
the system operator to return to step 152 of the method, or so 
to some other point of the method as required. 

Once the carrier space has been accounted for through 
sale or trade, a manifest or similar report can be generated 
and transmitted to the operator of the transport medium on 
which the carrier space exists. In so doing, the transport 65 
medium operator is provided with an up-to-date accounting 
of all space for a particular route. The manifest or similar 
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report can be generated at step 256, or alternatively could be 
an additional activity to be selected at step 262. 

As can be appreciated by those skilled in the art, a number 
of variations of the subject invention are possible. These 
variations include, but are not limited to: the ability of the 
system to print reports or generate billings for services at 
selected steps within the application; the use of a pop-up 
window instead of a pull -down menu when making deci- 
sions within the RDB locator program; the nature and scope 
of each of the hardware components of the data processing 
system; the ability of the system to handle more than one 
carrier and the carriers' respective rates; the ability to scan 
data into the system; the length of time intervals employed 
at steps 230 and 236; and, the extent to which data can be 
downloaded from the system to either a transfer media or to 
another data processing system. 

What is claimed is: 

1. A method for brokering carrier capacity comprisiog the 
steps of: 

(a) entering carrier capacity data from a first node into a 
transportation database in a data processing system, 
said capacity data identifying carrier capacity available 
by specific units of volume for a particular route at a 
particular time and identifying the mode of transpor- 
tation; 

(b) entering a request for a route into said data processing 
system at a second node by defining said requested 
route; 

(c) comparing said requested route with said carrier 
capacity data entered into said data processing system 
to determine whether or not a route match exists; 

(d) displaying a list of matching routes to a system 
operator; 

(e) selecting a matching route from said list of matching 
routes; 

(f) saving said matching route selection to a transaction 
database; 

(g) assigning a transaction code to said saved matching 
route selection; and 

(b) decrementing availability of said matching route 
selection from said data in said transportation database. 

2. The method of claim 1, wherein said data processing 
system utilizes a real time clock whereby said system can 
determine when carrier capacity listed in said data process- 
ing system can no longer be accessed because of a time/date 
threshold. 

3. The method of claim 1, wherein a transaction code is 
assigned to said matching route selection. 

4. The method of claim 2, wherein said entering capacity 
data step further comprises the steps of: 

(a) confirming said entry; 

(b) saving said entry in said transportation database; and 

(c) assigning a pre-transaction code to said entry. 

5. The method of claim 2, wherein said entering a request 
step further comprises the steps of: 

(a) defining a location start point of said route and a 
location end point of said route; 

(b) defining s desired date and time for shipping and 
arrival corresponding to said route start point and said 
route end point; 

(c) choosing a transportation medium; and 

(d) receiving a confirmation that said requested route has 
been entered into said data processing system. 

6. The method of claim 2, wherein if a null response is 
received when said requested route is compared with said 
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list of routes entered into said transportation database, then 
said requested route data is saved lo a request database. 

7. The method of claim 6, wherein a request database 
locator program is activated within said data processing 
system for the purpose of querying said transportation 
database at pre -determined time intervals to determine if a 
matching route selection has been entered into said trans- 
portation database. 

8. The method of claim 7, wherein if said matching route 
selection has been entered into said transportation database 
then a prompt is sent to a display device where said route 
request was made; said prompt indicating that a match has 
been found and that said system operator should enter said 
application to confirm said match. 

9. The method of claim 8, wherein if said matching route 
selection has not been entered into said transportation data- 
base then said request database locator program will con- 
tinue to query said transportation database at said pre- 
determined lime intervals until: (i) said date and time of said 
requested route has exceeded a date and time on said real 
time clock of said data processing system, or (ii) said query 
is terminated by said system operator. 

10. The method of claim 8, wherein said display is a 
monitor or a printer operative ly connected to said data 
processing system. 

11. The method of claim 2, wherein said data processing 
system is comprised of a plurality of entry points into said 
system and each entry point has data entry means for 
entering either carrier capacity to said system or entering a 
request for available routes into said system, or both. 

12. The method of claim 3, wherein a bill for services, a 
transaction report, or both, is prepared in respect of said 
transaction code. 

13. The method of claim 2, wherein said entering a 
request step further comprises the step of defining a location 35 
start point of said route and a location end point of said route 
by causing said start point and said end point to be entered 
into said data processing means by scanning said start point 
and said end point into said data processing means with a 
scanner or optical character reader from a label of a parcel 40 
to be shipped or from a printed media. 

14. The method of claim 1, wherein said first node and 
said second node arc co-located. 

15. Apparatus for brokering carrier capacity, comprising: 

(a) data processing mcaos for accepting a first listing of 45 
carrier capacity parameters for a delivery route and 
storing said parameters for later comparison to a second 
listing of requested carrier capacity parameters; 
wherein said carrier capacity parameters further com- 
prise volume increments, mode of transportation, and 50 
time parameters of said delivery route; said data pro- 
cessing means further for comparing said first listing to 
said second listing; 

(b) means for determining a matched entry on said first 
listing and said second listing based upon said com- 
parison of said carrier capacity parameters of said first 
listing and/or subsequent listings to said second listing; 

(c) means for displaying said matched entry to a system 
operator; 

(d) means for selecting said matched entry from among a 
possible plurality of matched entries; 
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(c) means for confirming said selection; and 
(f) means for decrementing a volume measurement rep- 
resentative of said selection from said stored carrier 
capacity parameters and further Cor recalculating the 
available capacity on the basis of units of volume 
available to said mode of transportation at a particular 
time. 

16. A method for brokering carrier capacity comprising 
the steps of: 

(a) entering carrier capacity data into a data processing 
system having a real time clock for comparing actual 
time with carrier capacity data; said entering step 
further comprising entering a list of parameters that 
define available carrier capacity by volume increments 
into said data processing system, confirming said entry, 
and then saving said entry io a transportation database 
as available routes and assigning a pre -transaction code 
to said entry; 

(b) entering a request for available routes into said data 
processing system, said request entry step further com- 
prising defining a route and confirming that said 
defined route is a requested route; 

(c) comparing said requested route with said available 
routes entered into said transportation database to 
determine whether or not a route match exists; 

(d) activating a request database locator program" within 
said data processing system for the purpose of querying 
said transportation database at predetermined time 
intervals to determine if a matching route selection has 
been entered into said transportation database; 

(e) displaying a list of matching routes and corresponding 
pre-transactton code to a system operator; 

(f) selecting a matching route by selecting its code from 
said list of matching routes, and then confirming said 
matching route selection; and 

(g) saving said matching route selection to a transaction 
database and assigning a transaction code to said 
matching route selection. 

17. The method of claim 16, wherein defining a route 
further comprises the steps of: 

(a) defining i location start point of said route and a 
location end point of said route; 

(b) defining a desired date and time for shipping and 
arrival corresponding to said route start point and said 
route end point; 

and 

(c) choosing a transportation medium. 

18. The method of claim 17, wherein said transportation 
medium comprises a plurality of modes of transportation. 

19. The method of claim 17, wherein said transportation 
medium is a single mode of transportation. 

20. The method of claim 16, wherein a bill for services is 
prepared in respect of said transaction code. 

21. The method of claim 16, wherein a transaction report 
is prepared in respect of said transaction code. 
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[57] ABSTRACT 

The invention comprises a rating engine, system, and 
method for processing rating requests in a computerized 
rating system. One aspect of the invention is an object- 
oriented rating engine operable to receive a rating request 
associated with a carrier contract. The rating engine com- 
prises a base rating engine object operable for use on a 
computer and further operable to calculate a linehaul rate in 
response to the rating request. The base rating engine object 
further comprises a rating method operable to calculate a 
linehaul rate and a rate data structure comprising at least one 
rate value. The rate data structure is accessible by the rating 
method for use in calculating a linehaul rate. 
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MODULAR RATING ENGINE, RATING A linehaul rate comprises the price charged to move a 

SYSTEM AND METHOD FOR PROCESSING particular shipment between two points. Contracts often 

RATING REQUESTS IN A COMPUTERIZED include prices for services provided other than linehaul 

RATING SYSTEM service. Examples of such services include hand unload, 

5 stopofls, tarps, warehouse service, etc. A table of example 

CROSS-REFERENCE TO RELATED services is provided below. 

APPLICATIONS a particular carrier may have many contracts with a given 

_. . IIC „!• Q , r w ~ customer. These contracts will typically have different quali- 

n C 2£ ^ *?t a r f ; fx LisS ' ficati ° ns ******* with ihem - F ° r exam P ie - a p artieuiar 

08/905,676 filed on Ajg 4. 997, by Henrik D^-Klcin w carrier have |e ^ a customer for eacfa 

m "i' h ' J S V °f the fol,owin g ^ ^ services: flatbed service, truckload 

, . service, less than truckload service, truckrail service and 

This application is related to U.S. application Ser. No. refrigerated trailer service. A carrier and customer may also 

08/905,808 filed on Aug. 4, 1997, by Henrik Danford-Klein, haye mulliplc contracts f or a particular type of service. For 

et al. and entitled, "Qualification . Engine, Rating System, 15 exarnp ie t a carrier and customer may have different contracts 

and Method for Qualifying Rating Requests in a Comput- fof , es£ . thjm lruckload ge^ce based upOQ t h e freight class 

erized Rating System." of the goods oe j ng shipped. In addition, the prices charged 

TPPHMir ai pifi n np thf IMVFNTION various customcrs m ^ var ? de P endin S u P° n the volume of 

TECHNICAL FIELD OF THE INVEN1ION business conducted. In summary, a customer may have 

This invention relates generally to computerized rating 2° ma0 y different contracts with a particular carrier and a 

systems and more particularly, to a rating engine, system and particular carrier may have many contracts with different 

method for processing rating requests in a computerized customers for the same or similar services, 

rating system. Customers may also have multiple contracts with many 

different carriers. Customers shipping a large amount of 

BACKGROUND OF THE INVENTION , 25 goods mav excced the shipping capacity of even SCV eral 

Members of the transportation industry contract with their carriers combined. Certain carriers may only ship goods 

customers to ship goods by truck, rail, ship, plane or other within certain regions, necessitating contracts between a 

forms of transportation. Some transportation companies, customer and multiple carriers. In addition, a customer may 

such as Federal Express, may not have written contracts with desire to have contracts with multiple carriers in order to 

small volume customers or individuals. On the other hand, induce greater price competition. The term contract is also 

Federal Express may have a written contract with special meant to broadly refer to shipments pursuant to a tariff, 

pricing and/or volume discounts for a larger customer, such circular, or other type document. 

as General Motors. Truckload carriers, such as Schneider Because both customers and carriers may maintain a large 

National Carriers, Inc. often sign written contracts with ^ number of contracts, management of these contracts pre- 

customers that regularly ship large quantities of goods. sents additional difficulties. To simplify this management 

These contracts will ordinarily specify whether a carrier will task, customers, carriers, and logistics companies have 

transport a load from one location to another, the conditions employed computer software to calculate the price for a 

under which such transportation can occur, the price for such given shipment and to generate orders, bills, checks, and 

transportation, and the price for additional services associ- 4Q electronic payment for the shipment. Customers holding 

ated with that particular shipment. contracts with multiple carriers may use such software to 

Accordingly, a particular contract between a carrier and a compare prices available for a particular shipment so that the 

customer contains (1) qualifications thai must be met for a customer pays the lowest price for the shipment. This 

shipment to occur pursuant to the contract, and (2) price Unction is normally referred to as best rate lookup, 

terms for shipments that meet the qualifications for use of 45 Some existing systems capable of calculating the price of 

that contract. The term "contract" is meant to be broadly a given shipment (rating) employ relational databases to 

interpreted and may, but does not necessarily, refer to a store the data necessary to calculate a price. Unfortunately, 

single written contract between a carrier and a customer. A each contract may include a large amount of price data, date 

single written contract might contain several different sets of ranges for which the price data is valid, and qualifications 
qualifications with a unique set of prices associated with 50 specifying the conditions under which such prices are appli- 

each set of qualifications. A written contract between a cable. Due to the many possible qualifications and date 

carrier and a customer might contain multiple contracts as restrictions, these relational databases contain a large num- 

described here, or a contract may be the combination of berof keys used to search the database. Although such keys 

multiple written contracts between the carrier and customer. are not considered to be redundant data in a relational 

The qualifications associated with a particular contract 55 dalabase - the rcalitv » that data ends U P bcin S rc P licated 

limit the types of shipments allowed under the contract. many times for use as a key for searching the database. 

Qualifications associated with a contract also specify the The use of relational databases for performing rating has 

conditions under which particular prices for services pro- a number of disadvantages. The large amount of redundant 

vided pursuant to the contract apply. Examples of qualifi- data resulting from the large number of keys in the database 
cations include, but are not limited to, equipment type, 60 causes a substantial increase in storage requirements, 

freight class, service type, weight, transportation mode, Because the database is large, access times to retrieve the 

contract type, product class, product identification number, relevant data are relatively slow. Locating the relevant data 

elc in the database can take an unreasonable amount of lime 

Contracts also include prices for services associated with compared to the needs of many businesses utilizing such 
shipments meeting the qualifications of the contract and 65 software. 

provided pursuant to the contract. One type of service often Relational databases cause performance problems as well, 

provided pursuant to a particular contract is linehaul service. A substantial amount of time is wasted in such systems 
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searching for price data that turns out to be unusable because 
the qualifications for use of the price data are not met. To 
determine that the price data is unusable, the data must still 
be located in the database. After locating the data, all of the 
relevant qualifications are matched against the rating request 
and if a particular condition is not met, then all of the time 
locating the relevant data has been wasted. 

Performance problems are magnified when a customer or 
logistics company desires to perform optimization. Optimi- 
zation requires the performance of even more calculation as 
the software must compute the price charged by multiple 
carriers for a particular shipment. 

SUMMARY OF THE INVENTION 

The present invention attains improved performance ver- 
sus existing systems by employing modular rating engines to 
achieve a logical grouping of contract rating data used to 
calculate line haul rates. One aspect of the invention is an 
object-oriented rating engine operable to receive rating 
requests associated with a carrier contract. The rating engine 
comprises a first base rating engine object operable for use 
on a computer and further operable to calculate a linehaul 
rate in response to the rating request. The base rating engine 
object further comprises a rating method operable to calcu- 
late a linehaul rate and a rate data structure comprising at 
least one rate value wherein the rate data structure is 
accessible by the rating method for use in calculating a 
linehaul rate. 

The invention has several important technical advantages. 
The invention allows a modular approach to construction of 
rating engines that creates a flexible system from which a 
complex rating engine for a particular carrier contract may 
be created. This modular approach also allows new types of 
rating engines to be easily developed without affecting the 
function of existing rating engines. Because rate calculation 
for many different types of rates is similar, the use of 
modular rating engines allows the invention to take advan- 
tage of these similarities, making data entry easier, reducing 
data redundancy, and, in tum, reducing storage require- 
ments. The use of modular rating engines also greatly 
increases the speed for calculating the cost of linehaul 
service in response to a rating request. 

Another aspect of the invention is the grouping of rating 
data by effective dates. According to this aspect of the 
invention, rating data for a particular carrier contract may be 
grouped together such that the rating data contained in a 
particular rating engine object is valid only for a date range 
that applies to all data contained in the object. The grouping 
of rating data by effective date avoids the redundancy of 
storing date information at the lane level, thus lowering 
storage requirements and increasing calculation speed. The 
invention avoids unnecessary data location operations by 
determining quickly whether a particular rating engine has a 
date range applicable to the rating request. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present inven- 
tion and the advantages thereof, reference is now made to 
the following descriptions, taken in connection with the 
accompanying drawings, in which: 

FIG. 1 illustrates an example of a computer network 
configuration that may be used for a computerized rating 
system constructed in accordance with the invention; 

FIG. 2 illustrates a diagram of an exemplary general 
purpose computer that may be used in the network of FIG. 
1; 
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FIG. 3 illustrates a block diagram of a client that may be 
used in a computerized rating system constructed in accor- 
dance with the invention; 

FIG. 4 illustrates a block diagram of a rating server that 
5 may be used in a computerized rating system constructed in 
accordance with the invention; 

FIG. 5 illustrates a diagram of a portion of a computerized 
rating system constructed in accordance with the invention; 
10 FIG. 6 illustrates an object class diagram comprising a 
portion of one embodiment of a computerized rating system 
constructed in accordance with the invention; 

FIG. 7 illustrates an object class diagram of a portion of 
a second embodiment of a computerized rating system 
15 constructed in accordance with the invention; and 

FIG. 8 illustrates an object diagram of a portion of a 
computerized rating system constructed in accordance with 
the invention. 

20 DETAILED DESCRIPTION OF THE 

INVENTION 

The preferred embodiment of the present invention and its 
' advantages are best understood by referring to FIGS. 1-8 of 
the drawings, like numerals being used for like and corre- 

25 sponding parts of the various drawings. 

FIG. 1 illustrates a computer network 10 that may be used 
for a computerized rating system constructed in accordance 
with the teachings of the invention. Although the invention 

3Q is shown in a client server environment, the invention can be 
used in any computer environment. Computer network 10 
comprises one or more client computers 12 connected 
through a computer network to one or more computers 14. 
In this example, one client computer 12 is running a client 

35 application 16 that may be used to perform a rating operation 
by accessing contract data associated with carrier contracts. 
Rating server application 18 is running on server computer 
14 and is operable to receive rating requests from client 
application 16 through computer network 10. Auser of cUent 

40 computer 12 that desires to determine the price for a 
particular shipment of goods, generate an order for such 
shipment, generate a bill for such shipment, and/or cause 
payment for such a shipment, uses client application 16 to 
generate such a request to rating server application 18. 

45 Rating server application 18 performs the necessary calcu- 
lations and returns the results to client application 16. 

FIG. 2 illustrates a general purpose computer 22 that may 
be used for client computer 12 and/or server computer 14 of 
FIG. 1. General purpose computer 22 may be used to 

50 execute applications comprising computerized rating sys- 
tems constructed in accordance with the present invention. 
General purpose computer 22 may be adapted to execute any 
of the well-known MS-DOS, PC-DOS, OS2, UNIX, MAC- 
OS and WINDOWS operating systems or other operating 

55 systems. General purpose computer 22 comprises processor 
24, random access memory (RAM) 26, read only memory 
(ROM) 28, mouse 30, keyboard 32 and input/output devices, 
such as printer 36, disk drives 34, display 38 and commu- 
nications link 40. The present invention includes programs 

60 that may be stored in RAM 26, ROM 28 or disk drivers 34 
and may be executed by processor 24. Communications link 
40 is connected to computer network 10 but could be 
connected to a telephone line, an antenna, a gateway, or any 
other type of communication link. Disk drives 20 may 

65 include a variety of types of storage media such as, for 
example, floppy disk drives, hard disk drives, CD ROM 
drives, or magnetic tape drives. Although this embodiment 
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employs a plurality of disk drives 34, a single disk drive 34 or classes for data passing. In other words, communication 

could be used without departing from the scope of the objects module dynamic link library 46 may provide a 

invention. FIG. 2 only provides one example of a computer library of structures that may be used by client rating module 

that may be used with the invention. The invention could be dynamic link library 44 and/or request packager module 

used on computers other than general purpose computers, as 5 dynamic link library 48 to pass data to server computer 14. 

well as on general purpose computers without conventional FIG 4 illuslrates a b i ock diagram of an embodiment of 

operating systems. rating server 18 constructed in accordance with the inven- 

FIG. 3 illuslrates a block diagram of an embodiment of Uon Rating sefver 18 may be stored in 2 6, ROM 28, 

client 16. Client 16 may be stored in RAM 26, ROM 28 or of ^ dfives 34 of general purpose computer 2 2 or in 

disk drives 34 of general purpose computer 22 or on a 10 aQ0lher location _ In addition, both client 16 and rating server 

different computer. Client user interface 42 uses client 16, lg may be stQred 00 , he same computer Rating xvn[ 18 

which comprises client rating module dynamic link library comprises ratin g mo dule dynamic link library 54, commu- 

44, communication objects module dynamic link library 46 nication objects modu]e dynamic link library 56t requesI 

request packager module dynamic link library 48, and packagcr modu [ e dynamic link library 48, server API 58, 

network communication module dynamic link library 50. 15 ra(e calculator 59) a(ld netW ork communication module 60. 

This embodiment of client 16 comprises a 32-bit version 0DM module DLL 52 uses rating 18 and may attain 

employing WINDOWS dynamic link libraries. Other such access ei(her through fating module DLL 54 or serve,- 

embodiments of client 16 may include a 16-bit version ^ $g ApplicatioQS will preferably access rating server 18 

implemented with WINDOWS dynamic link libraries and a ■ scrver ^ 58 unkss it is incapable of using applica- 

UNIX version. The 16-bit WINDOWS version of the client 20 tion B rogram interfaces. 

application employs *™^^^^^° a - In operation, network communication module 60 receives 

monly performed ,n the WINDOWS operating system. , & ^ ^ ^ and ^ ^ com ^ d 

A client user interface 42 desiring to obtain rating infer- s( tQ ^ 5g Servcr ^ 5g generates thc 

mation will make a request using chent rating module rialc call t0 rate calculator 59, which comprises a 

dynamic link library 44. This request will result in procedure 25 , mk |ib ^ of the ca(cuIation arc 

calls to client rating module dynamic link library 44. Client tQ |he ne[work b Api 58 and netW0fk 

rating module dynamic link library 44 provides access to commumcations module 60 . 

functions of me rating server 18. Chent rating module Mlemi{iye] & can be made through rating mod . 

dynamic link library 44 provides access to the same , *j • • -i . .u * j -v. a -.u 

j .. r j ■ ,u j 1a j, m „ m „r„i, ule DLL 54 in a manner similar to that described with 

exported functions found in the rating module dynamic link 30 „.„ - . .. K«j- mMl „„„. ct «,-v a „- r 

* , 10 i.- u 11., l^„ t ^ r,r, respect to FIG. 3. In this embodiment, request packager 

ubrary of ratmg server 18 which normally executes on 7. , . , ,, aq-«-a- ^..t.^* 

. ia n l .u ~* a a module dynamic link library 48 is identical to its counterpart 

server computer 14. By having the same exported functions " 3 J f,,^,? c 

, . .... . * 1 , 1 . 1 1 *i aa a in client 16, but could be tailored to specific functions 

for both the chent rating moduledynamic link library 44 and 1U . " t . 1fl ~ Mma . fnr „„ mm „ 

. . 11 , „■ . „, „ f tU „ required by rating server 18, The same is true for commu- 

the rating module dynamic link library of the rating server .1 ' 6 , , . 

, , l j - . u ui nication objects module DLL 56 and network communica- 

18, the dynamic link libraries may be used interchangeably. 35 " / nT , * ft 

This means that if there is a need for a stand-alone version ll0n moaule ULL ou ' , 

of the system, a user may obtain the rating module dynamic Server API 58 may be used to access rating service* It 

link library for rating server application 18 and substitute it allows queries of statistical information, as well as control of 

for client rating module dynamic link library 44. In other ">ting calculator 59. Statistical information includes current 

words, a particular user may be given a personal copy of the «, connections, execution duration and total connections, 

rating information maintained by the rating module dynamic Server API 58 may unload and reload rating calculator 59, 

link library of rating server 18. as wel1 35 reload 5 P eciflc rate ^formation for a given rating 

Returning to the operation of client 16, client rating <f**f* 59 Server ? 8 uses the same ™**fj^ X 

module dynamic link library 44 will make appropriate calls data formatting via network communication module 60 as 

to request packager module dynamic link library 48. Based 45 UJ * d * ffS ? T \ * InT ^ * 

upon the service requested, request packager module "odule DLL 54. Accordmgly server API 58 may be run on 

dynamic link library 48 will build a request object which ^ com P u * r has access 10 rat ^ c f lcul f tor » on «™ 

contains an identifier for the function desired on rating computer 14. Such access may include network access, 

server 18, the total amount of data to send, and any addi- ODM module dynamic link library 52 comprises an 

tional objects required as input parameters to the function on 50 optimization data manager application that may be used to 

rating servcr 18. The request packager module dynamic link perform optimization functions, such as identifying the least 

library 48 will then call a send-type function in the network expensive carrier for a specific shipment of goods. ODM 

communication module dynamic link library 50 and will module dynamic link library 52 may directly access func- 

wait for a result object to be returned. tions in server API 58 or indirectly through rating module 

Network communication module dynamic link library 50 55 dynamic link library 54. 

will send the request packet and additional objects to server Although examples of client 16 and rating server 18 have 

computer 14. After server computer 14 has completed pro- been provided, other embodiments could be used without 

cessing the request, it sends the result back to network departing from the scope of the invention. In addition, 

communication module dynamic link library 50, which different embodiments may be created for different operat- 

returns it to the request packager module dynamic link 60 ing systems and/or environments. Finally, the teachings of 

library 48. When request packager module dynamic link the present invention may be used for a stand-alone appli- 

library 48 receives the return data packet, it breaks it down cation rather than an application used in a client server 

into the appropriate objects and passes the data back to client environment. 

rating module dynamic link library 48. Client rating module FIG. 5 illustrates an architectural diagram of a portion of 

dynamic link library 44 returns the data and/or result to the 65 rate calculator 59 in rating server 18. In a computerized 

calling function in client user interface 42. Communication rating system constructed in accordance with the invention, 

objects module 46 may provide a common set of structures data is organized based upon carrier contracts. Each carrier 
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contract is associated with at least one carrier contract object contracts such as base, continuous move, round trip, 

62. Thus, at least a portion of a computerized rating system dedicated, and/or expedite. Product class may generally 

constructed in accordance with the teachings of the inven- refer to classes of products such as frozen, refrigerated, 

tion is object-oriented. As shown in FIG. 5, a particular heated, or dry. 

carrier contract object 62 may access a qualification engine 5 Qualification engine 64 has access to a plurality of sets of 

64, service engine 66, and/or rating engine 68. qualifications. Each qualification set includes one or more 

n , , , , v , t . > ha m qualifications applying to a particular class of contracts. The 

Hie functions performed by qualification engine 64 ser- ^J^J of the fact that many participants 

vice engine 66, and rating engine 68 are best understood by ^ (he transportation industry use contracts with identical 

examining the operation of these engines m calculating the qualificatirjns for identical types of services. For example, 

price for a particular shipment. Although the function will be « that ^ refrigerated trailer ^ may 

described in more detail below, a brief overview is now faave ^ same lificalions assoc iated with their contracts 

provided. Carrier contract object 62 is operable to receive a for refrigerated scrvicCi similarly, many truck rail equip- 

rating request containing a collection of data parameters ment may haye identical qua iifi ca tions for their 

specifying all of the information needed to calculate the lruck ra ji ^^^6 contracts with customers. By taking advan- 

price of a particular shipment of goods from one point to Qf simiIarities in qualifications, the invention reduces 

another, including all services associated with that request. (he amounl of da(a redundancyi as a single set of qU alifica- 

Carrier contract object 62 first uses qualification engine 64 ^ data need onJy bc stored onc£ and can be used with 

to determine whether the carrier contract represented by contracts. The qualification engine 64 is also flexible 

carrier contract object 62 is qualified based upon the con- £ fa tQ hand]e contracts that may on]y apply t0 a 

ditions specified in the rating request. If carrier contract 20 & ^ ^ ^ ^ 

object 62 is not qualified to process the rating request, then tomer Jn such a ^ a special qualiflcation ^ & create d for 

a rate not found message is returned in response to the rating (ha( carrief and caQ ^ accessed by qualification 

request. If the carrier contract is qualified to process the engine 54. The inveotion thu s takes advantage of similarities 

rating request, then it determines the price for the shipment ^ ufications between cont racts, but remains flexible 

identified in the rating request using service engine 66 and 25 ^ ^ & 

rating engine 68. Qualification types fail into two major categories: match- 
Rating engine 68 calculates the linehaul rate correspond- ing and first type, matching qualifications, 
ing to the rating request. Service engine 66 may be used to com prise a qualification type and a value. Matching quali- 
calculate the price of all other relevant services that are ^ ficat i ons are generally used where a qualification parameter 
called for by a rating request. There are many different types &enl with a rating request has to match a member of a 
of services that may be provided pursuant to a rating request. qualification set exactly. For example, equipment type will 
Examples of such services are included below in Table 1. norma lly be a matching type qualification. A rating request 
The cost of linehaul service is calculated by this embodi- for a van trailer would normally specify a 45-foot, a 48-foot, 
ment of rating engine 68, while the cost of other services are 35 Q r a 53-foot van trailer. To be qualified, the carrier contract 
calculated by service engine 66. In an alternative invention would have to be associated with a qualification set that 
(not explicitly shown), the cost of linehaul service could be includes a van trailer of 45 feet, 48 feet, or 53 feet, 
calculated by service engine 66. In such an alternative The other category of qualification types is bounds quali- 
embodiment, the functions of rating engine 68 would be fications. Bounds qualifications normally comprise a quali- 
incorporated into service engine 66. Thus, the cost of m fiction type, a bound operand, and a value. To determine 
linehaul service may be treated as just one type of service whether a particular qualification parameter supplied with a 
that may be called for by a rating request. Depending upon rating request meets a bounds-type qualification contained in 
the design of service engine 66, it may be desirable to have tne qualification set, the value of the qualification parameter 
a separate rating engine 68 to calculate the cost of linehaul ^ compared with the value of the qualification stored in the 
service. 45 qualification set using the bound operand. For example, load 
In this embodiment, qualification engine 64 comprises weight may be a bounds-type qualification. A particular 
one or more software objects. An exemplary embodiment of carrier may desire not to carry any load over 50 tons. In such 
qualification engine 64 will be discussed below in connec- a case, a qualification in the qualification set may be that 
tion with FIGS. 6 and 7. In this example, qualification load weight is less than 50 tons. In this example, the 
engine 64 comprises an instance of a qualification engine 50 qualification type is load weight, the bound operand is less 
object class and is contained in carrier contract object 62. than, and the value is 50 tons. In processing a rating request, 
The use of qualification engine 64 facilitates grouping of qualification engine 64 would compare the load weight 
rating data by qualifications. Grouping of data by qualifi- provided with the rating request and determine whether it 
cations results in faster access to rating data, as well as a was less than 50 tons. If so, then the qualification engine 64 
large reduction in redundant data compared to existing 55 would determine that the carrier contract was qualified for 
systems. Qualifications limit the types of shipments that the shipment corresponding to the rating request, assuming 
rating data applies to. As noted above, carriers often have that all other qualifications were met. 
multiple contracts with a particular customer where each In summary, a qualification request may include a quali- 
contract has different qualifications. In this embodiment, the fication parameter comprising a parameter type and a param- 
qualifications associated with a particular contract may 60 eter value. To determine whether this qualification parameter 
include, but are not limited to, equipment type, freight class, meets a bounds type qualification in a qualification set, 
contract type, transportation mode, weight value, service qualification engine 64 compares the qualification parameter 
level, stop value, bill-to code, quote number, and/or equip- to the bounds qualification requirement, wherein the quali- 
ment owner identification. Transportation mode refers to fication type of the bounds type qualification requirement 
various different types of transportation such as rail, small 65 matches the qualification parameter's parameter type and the 
package, less than truckload, truckload, truck rail, qualification engine compares the parameter value to the 
refrigerated, etc. Contract type refers to various types of bounds type qualification value using the bound operand. If 
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the parameter value is within the bounds set by the bound 
operand and qualification value, then a true result is pro- 
duced in response to the comparison. 

Qualification engine 64 implements matching-type quali- 
fications by using an equality operator between the qualifi- 
cation type and qualification value in the qualification set. In 
a sense, then, all qualifications can be implemented as 
bounds-type qualifications in this embodiment of the inven- 
tion. Qualification sets could be implemented differently, 
however, without departing from the scope of the invention. 

The equipment type qualification cited in the example 
above could be implemented as a bounds type qualification. 
In this embodiment of qualification engine 64, each equip- 
ment type is assigned a numerical equipment ID. If a 
particular qualification set included equipment types 10-15, 
then the qualification set could include a range-type bounds 
operand where the equipment ID range is between 10 and 
15. This example also illustrates that a bounds type quali- 
fication might have multiple bounds values associated with 
it, particularly when a range operand is employed. 

To determine whether a carrier contract is qualified to 
process a particular rating request, carrier contract object 62 
generates a qualification request to qualification engine 64. 
Qualification engine 64 then determines whether the set of 
qualification parameters passed with the qualification 
request is a subset of the qualification set associated with the 
carrier contract represented by carrier contract object 62. 

For example, suppose that a standard flatbed contract has 
the following qualification set: equipment type equals 48 
foot flatbed trailer, equipment type equals 45 foot flatbed 
trailer, equipment type equals 48 foot flatbed sliding tandem, 
and weight is less than fifty tons. Suppose that the qualifi- 
cation request to qualification engine 64 contains the fol- 
lowing parameters from a rating request sent to carrier 35 
contract object 62: equipment type equals 45 foot flatbed 
trailer, and weight equals thirty tons. In this example, 
qualification engine 64 would determine that the contract is 
qualified to handle this request. The two member set of 
qualification parameters is a subset of the four member 40 
qualification set, taking into account bounds operands. The 
equipment type parameter appears in the qualification set 
and the weight parameter satisfies the condition imposed by 
the bounds type weight qualification in the qualification set. 
If, on the other band, the qualification parameter for equip- 
ment type was for a fifty-three foot van trailer, then quali- 
fication engine 64 would have returned a negative response 
to the qualification request indicating that the carrier con- 
tract associated with carrier contract object 62 was not 



engine 68 comprises an object or objects contained in carrier 
contract object 62 and may also include one or more objects 
used by carrier contract object 62. 
After calculating a linehaul rate using rating engine 68, 
5 carrier contract object 62 will use service engine 66 to 
calculate the price for various additional services that may 
be included in the rating request. Similar to rating engine 68, 
service engine 66 comprises one or more software objects 
contained in carrier contract object 62 and may contain one 
10 or more objects used by carrier contract object 62. Again, the 
structure of service engine 66 will be described more fully 
in connection with FIG. 6 below. 

Although the structure illustrated in FIG. 5 provides one 
embodiment of a rating system constructed in accordance 
15 with the invention, various substitutions may be made 
without departing from the scope of the invention. For 
example, although qualification engine 64, service engine 
66, and rating engine 68 each include one or more objects 
contained in carrier contract object 62, these objects might 
20 only be used by carrier contract object 62 and not contained 
therein. In addition, rather than implementing these engines 
as separate objects, any one or more of these engines could 
be implemented as methods of carrier contract object 62. 
These engines could also be implemented as software mod- 
ules accessible through ordinary procedure calls from carrier 
contract object 62. 

Although a number of qualification types have been 
listed, more or less qualification types could be used without 
departing from the scope of the invention. A particular 
qualification set may include one or more of the qualification 
types and need not include a qualification of every type. 
Other categories of qualifications other than matching or 
bounds qualifications could also be used. 

FIG. 6 illustrates a class diagram of a portion of an 
exemplary computerized rating system constructed in accor- 
dance with the invention. In this embodiment, instances of 
the object classes illustrated in FIG. 6 will form a portion of 
rating server application 18. FIG. 6 illustrates the object 
classes that may be used to represent a particular carrier 
contract. As is commonly done in object class diagrams, an 
arrow on the line joining two object classes indicates 
inheritance, an open circle indicates that an object is used by 
another object, while a closed circle indicates that an object 
is contained in another object. 

In this embodiment, qualification engine object class 72 
defines the object class for a qualification engine. An 
instance of qualification engine object class 72 is contained 
in carrier contract object class 70. Carrier contract object 
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• qualified for the shipment requested pursuant to the rating 50 class 70 contains information about a specific carrier con- 
request, tract. Here, each carrier and each customer are assigned an 
As noted, this embodiment of qualification engine 64 identification number. Those numbers are stored in instances 
comprises an object contained in carrier contract object 62. of carrier contract object class 70. Carrier contract object 
Qualification engine 64 further comprises a qualifying class 70 contains a contract type identification and transpor- 
method operable to compare the qualification parameters 55 tation mode identification. An instance of carrier contract 
provided with a qualification request to a set of qualification ™ ™»»-«« /".ai-fi^t;™ ™a 
requirements to determine whether the carrier contract is 
qualified. 

If qualification engine 64 determines that carrier contract 
object 62 is qualified to handle a particular rating request, 60 
then carrier contract object 62 will determine the linehaul 
rate using rating engine 68. Rating engine 68 comprises one 



or more instances of a collection of rating engine object 
classes. Accordingly, rating engine 68 may be comprised of 
one or a plurality of software objects. The structure and 
operation of rating engine 68 will be more fully described in 
connection with FIG. 6 below. In this embodiment, rating 



65 



object class 70 also contains qualifications, rates and ser- 
vices which are implemented as a plurality of instances of 
the object classes illustrates in FIG. 6. These objects are 
contained in the instance of carrier contract object class 70. 
Carrier contract object class 70 also contains methods used 
for rating a request using the qualifications, rates and ser- 
vices. 

Qualification engine object class 72 comprises an object 
class. Each instance of carrier contract object class 70 also 
contains an instance of qualification engine object class 72. 
Qualification set object class 74 is an object class containing 
each of the qualification sets that may be used to qualify a 
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particular rating request. In this embodiment, only one set using messages sent to the single instance of qualification 

instance of qualification set 74 is used. Each instance of set object class 74. 

qualification engine object class 72 uses the single instance Although one embodiment of object classes that may be 

of qualification set object class 74 for qualifying a rating used to create a qualification engine have been illustrated in 

request 5 FIG- <>. other embodiments may be used without departing 

Certain qualifications may be considered so general that a from the ^P' 0 / inve[Uion *™ " mp £ ahh ° U ( gh " 

. \ . , . . , , .. . . ™ ■ j instance of qualification engine object class 72 is contained 

method contamed in carrier contract object class 70 is used ^ an J & q{ ^ ^ ^ ^ dass ?Q ^ oh . 

to partially qualify a rating request. In such a circumstance, ^ be used a carrier contract object ^ HficatioQ 

an instance of earner contract object class 70 would store at ^ bfi - n another ^ assod . 

least a subset of the qua hficaUons associated with that 10 ate B d with ^ ca ^ cr rontrad object . ^ e term « aSMciated " is 

earner contract. For example, in this embodiment, the con- used broa and ^ for j objects ^ b , he 

tract type and transportation mode qualifications are imple- objec( and/or objects contained in |fafi carrier 

mented by placing those quahficalions directly in carrier contract ^ thc lification c ine mM ^ 

contract object class 70. These qualifications could be placed im [emented as methods of tne carrier cootract object rather 

in one of the qualification sets stored in qualification set 15 ^ as & (c ^ ^ lificalion en ^ ne tould 

object class 74. Contract types include but are not hmited to even be a of dures not implemented in an 

one way moves, continuous moves round- trip moves and object . oriented fasbjont but accessib i e by a carrier contract 

dedicated moves Transportation modes include but are not ^ . lcmenlation uses an instance of 

limited to truckload/van, less than truckload, rail, air, J & 




considered to be such in the strictest sense, they may provide d - fferent . lementalion of the inventio[i ; 

convenient categonzat.ons for a computenzed rating sys- ^ quaUfication ^ is 

em ' , 25 stored in a single instance of qualification set object class 74, 

An instance of carrier contract object class 70 contains a ^ qualification set associated with a particular carrier 

qualification set identification that allows the qualification contract cou ld be stored as an instance variable in an 

engine to determine which qualification set in the instance of instance of carner conlract object class 70 or qualification 

the qualification set object class 74, to use for qualifying a engine object dass ?2 [n additio0j an instance of qualifi . 

particular rating request. This instance vanable could also be cation set objec , class 74 could be in each i asta0 ce 

stored in an instance of qualification engine object class 72. of qua i mcation engine ob j ect c i ass 72 rather than used by 

Qualification engine object class 72 comprises a method sucn aD instance. Multiple instances of qualification set 

operable to compare qualification parameters associated object class 74 could also be created such that each quali- 

with a rating request to a qualification set to determine fication set comprised a separate instance of the object class, 

whether the carrier contract is qualified to handle a particular J5 Any of these options and other options can be used without 

rating request. The sets of qualification requirements are departing from the scope of the invention, 

stored in qualification set object class 74. The data structure Turning to object classes relating to the rating engine 

containing the qualification sets is implemented as a list of function, the following object classes illustrated in FIG. 6 

lists. Each item in the primary list is a qualification set while may be ^ t0 create rat i ng engine 68 of FIG. 5: rating 

each item in a qualification set comprises a matching or ^ eng i ne ob ject class 96, collective rating engine object class 

bounds type qualification. In this embodiment, each element 93 base rat j ng engme ob j ect c i ass ioo, selective rating 

of a qualification set comprises a qualification ID, a bound engine object class 102, additive rating engine object class 

operand and one or more bound values. Other data structures 104 multiplier rating engine object class 106, minimum 

could be used to store the qualification sets without depart- rating engine object class 108, maximum rating engine 

ing from the scope of the invention. 45 ob j ect class no, standard YF 500 discount rating engine 

This embodiment requires certain qualification param- object class 112, zone zone rating engine object class 114, 

eters to be present in any rating request. The contract type, zone value rating engine object class 116, band value rating 

transportation mode, equipment type, and commodity type engine object class 118, LTL rating engine object class 120, 

are all required parameters. These qualification types may or direct rating engine object class 122, YF 500 object class 92, 

may not be utilized by an instance of qualification engine 50 and YF 510 object class 94. Because of the modular archi- 

object class 72 to qualify a given rating request but are lecture of this embodiment of the invention, an actual rating 

required to be in that request in case they are needed to engine comprises instances of one or more of these objects 

qualify the request. The commodity may be identified by the contained in an instance of carrier contract object class 70, 

freight class, product class or product identification number. Exceptions to this rule are instances of YF 500 object class 

More or less qualifications may be required to be included 55 92 and YF 510 object class 94. Only a single instance of 

in a rating request without departing from the scope of the these objects exists in this embodiment of the invention and 

invention. these objects may be used by an instance of carrier contract 

Other qualifications may include weight, service level, object class 70 and/or LTL rating engine object class 120. 

stop/activity type, bill-to code, quote number, equipment Other types of standalone rating engine object classes such 

ownership, terms and volume number. The volume number 60 as YF 500 object class 94 could be included and links 

would be used for contracts applying to special volume maintained to carrier contract object class 70 without depart- 

discounts. Again, other qualifications could be used or some ing from the scope of the invention. Such engines may be 

of these qualifications not used without departing from the preferable where rating data is consistent for many contracts, 

scope of the invention. The operation of instances of quali- Rating engines are designed to process different rate 

fication engine object class 72 is described above with 65 structures which include geography matrices, mileage 

respect to qualification engine 64 illustrated in FIG. 5. bands, weight bands and complex combinations of these 

Qualification engine 72 accesses a particular qualification matrices and bands. These base rating engines contain the 
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actual price data used to calculate the price for linehaul 
service. The price data is made up of an index type, 
origin/destination type or band type, a unit of measure, and 
effective dates. In addition to these specific base rating 
engines, there are rating engines which are collections of 
rating engines. Such rating engines are known as collective 
rating engines and include the selective, additive, multiplier, 
minimum, and maximum engines. Collective rating engines 
do not contain actual price data but instead contain other 
rating engines which could be base rating engines, as well as 
other collective rating engines. Collective rating engines 
also include the methods for uniquely processing the asso- 
ciated collection of rating engines. 

Each rating engine associated with an instance of carrier 
contract object class 70 will be of a specific engine type, unit 
of measure code, effective start dale, and effective end date. 
Other characteristics may be included, or some of these 
characteristics may be omitted from the rating engine with- 
out departing from the scope of the invention. As will be 
described more fully below, a rating engine may turn out to 
be a tree of instances of rating engine objects. In order to 
represent this hierarchy, each rating engine maintains a field 
noting its parent and a field noting its priority. Priority will 
also be discussed below. 

The modular approach to constructing rating engines 
creates a flexible system from which a complex rating 
engine for a particular instance of carrier contract object 
class 70 may be created The modular approach also allows 
new types of rating engines to be easily developed without 
affecting the function of existing rating engines. Modularity 
also greatly increases the speed for calculating the cost of 
linehaul service in response to a rating request. Because rate 
calculation for many different types of rates is similar, the 
use of modular rating engines allows a computerized rating 
system constructed in accordance with the invention to take 
advantage of these similarities, making data entry easier, 
reducing data redundancy and, in turn, reducing storage 
requirements and allowing rating information to be loaded 
directly into memory of server computer 14. 

In the embodiment illustrated in FIG. 6, all specific base 
rating engines and specific collective rating engines inherit 
from either collective rating engine object class 98 or base 
rating engine object class 100 and, in turn, from rating 
engine object class 96. Therefore, these engines are all 
descendants of some basic type of engine and have specific 
attributes and methods which facilitate the effective decom- 
position of a very complex data model. 

Before discussing more details of bow a rating engine is 
constructed using the noted object classes, the function of 
various specific base and collective rating engines will now 
be discussed. Zone value rating engine object class 116 is 
designed to support a geography structure for assigning a 
price to an origin zone or a destination zone. Such a base 
rating engine will be useful to implement an engine for 
calculating destination fees for calculating continuous move 
costs. This rating engine is designed to return a price value 
based upon a geographic zone. 

An instance of zone zone rating engine object class 114 
will support geography structures for determining the price 
of an origin/deslination-type charge. The rate structure for a 
particular carrier contract can be as simple as a state-to-state 
matrix or can also have an override matrix for Zip 3 to Zip 
3 within it. These types of matrices may be implemented 
using a zone to zone rating engine. An origin or destination 
may be specified by its five-digit zip code (Zip 5), three-digit 
zip code (Zip 3), standard point location code (SPLC), stale 
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and/or country. Accordingly, an instance of zone zone rating 
engine object class 114 may be used to calculate origin/ 
destination linehaul service charges for a shipment between 
the following origin/destination combinations: Zip 5 to Zip 

5 5, SPLC to SPLC, SPLC to Zip 3, SPLC to State, Zip 3 to 
SPLC, Zip 3 to Zip 3, Zip 3 to State, State to SPLC, State 
to Zip 3, Zip 3 Range to Zip 3 Range (open ranges), State 
to State, and Country to Country. Other origin/destination 
combinations could be implemented using zone zone rating 

io engine object class 114 without departing from the scope of 
the invention. 

Band value rating engine object class 118 may be used to 
implement a rating engine that maps a price to a band of 
values for a specific unit of measure. Accordingly, this object 

!5 class may be used to implement weight band and mileage 
band rate structures. 

Direct rating engine 122 may be used to implement an 
engine to calculate a price for a contract that contains just 
one price structure which includes the price and minimum 

20 charge. This type of rating engine is useful to implement 
charges for services with a flat rate. For example, Federal 
Express may have a fiat rate for shipping a product with a 
certain class of service in the United States. 

YF 500 object class 92 and YF 510 object class 94 are 
used to calculate the Yellow 500 less than truckload tariff 
and Yellow 510 less than truckload tariff, respectively. 
Because of the large amount of data involved for these two 
tariffs, a computerized rating system implemented in accor- 

3Q dance with this embodiment of the invention, will only have 
a single instance of these two object classes that will be used 
by an instance of LTL rating engine object class 120 and/or 
an instance of carrier contract object class 70. 
Standard YF 500 discount rating engine object class 112 

35 is used to implement an engine to calculate a discount to 
apply to the Yellow 500 tariff. This engine will be based on 
a standard discount tariff for Yellow 500. It will comprise an 
origin discount based upon a Zip 3 origin, a destination 
discount based on a Zip 3 origin, a global discount, and a 

40 service area defined by Zip 3 ranges. The logic of an instance 
of standard YF 500 discount rating engine object class 112 
will verify that the origin or destination of the request are 
both in the service area vector and will stop if they are not. 
The object will then look up an origin discount in the origin 

45 discount vector. If an origin discount is found, then that 
discount will be returned; otherwise, the object will con- 
tinue. If an origin discount was not returned, then the object 
will search for a destination discount and the destination 
discount vector and return one, if found. If no origin or 

50 destination discount was found, the object will return the 
global discount. 

Turning now to the function of specific collective rating 
engines, a general description of a collective rating engine 
may prove helpful. An exemplary collective rating engine 

55 contains a list of rating engines and a method to rate a 
request against the list. In some collective rating engines, 
this list is an ordered list organized primarily by a priority 
value, and secondarily by the effective start date assigned to 
the rating engine. Each collective rating engine is operable 

60 to perform an operation on linehaul rates calculated by 
rating engines on the list of rating engines maintained by the 
collective rating engine. Note that the list of rating engines 
that the collective rating engine operates on can include both 
base rating engines and collective rating engines. FIG. 8 

65 illustrates an example of the use of collective rating engines. 
The use of collective rating engines results in a tree-like 
structure where each node in the tree comprises either a base 
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rating engine or a collective rating engine. Each leaf node of still results in lower storage requirements and faster pro- 

the tree comprises a base rating engine object, while each cessing times because if rating data was not grouped by 

non-leaf node of the tree will comprise a collective rating effective dates, then a more complicated representation of 

engine object. The term "leaf node" refers to a node of the ra tes at a lower level wouid significantly increase the size of 

tree that has a parent node, but no children nodes associated 5 ra i e da t a tables. In addition, if date information is stored at 

with it. Note that the resulting tree frequently is not binary, a i ower [ eve i t substantial additional processing is required to 

as a collective rating engine may operate on more than two determine whether the date fell within the date range appli- 

rating engines. cable to a particular rating data item. The invention obtains 

The function of the various collective rating engines will a performance benefit, both by facilitating the loading of rate 

now be described. An instance of selective rating engine 10 tables in memory rather than storage on a disk, as well as by 

object class 102 will loop through its vector of rating engines not having to search through a limited set of date ranges 

and will st op when a rating engine finds a rate. Note that the before obtaining an individual rate data item at the lane 

term "rate" is used broadly to mean calculating a price, a j eve i pjc. 8 will be used to illustrate how the start date and 

multiplier to be applied to a price, or some other numerical end date associated with a rating engine affects the operation 

or boolean value for a particular service. Although the rating 15 0 f me overa u rating engine. 

engine will calculate a rate for linehaul service, each of the ^ q{ fating eQgine objcct dass 104 wiU 

individual base and collective rating engines making up the . (h . {t& vecU)r of rating eQgines and win add , he 

overall rating engine may compute intermediate results that calculated by those rating engincs together , For 

may also be referred to as rates. Accordingly, the term rate exampIet a continuous move operation would use this rating 

may refer to a particular parameter used to calculate the 2Q e lQ ^ A ^ results frQm a zone ^ type engine with 

overall price for a shipment of goods. A rate may not always (he resul(s of a destination fee ca i culated by a zone value- 

be determinable by a particular base rating engine or col- engine 

lective rating engine. Instead, a rate not found message may yv , . . 

be returned by a particular base rating engine or collective An instance of multiplier rating engme object class 106 

rating engine Thus, an instance of selective rating engine 25 Wl1 loop through its vector of rating engines and wiU 

object class 102 will attempt to obtain a rate by looping mult .ply all of the results together. Us^ than truck load rating 

through its ordered vector of rating engines and will stop "jay use this type of engine to mu tiply the cost of 

when one of those rating engines returns a rate rather than the } es ? *an truckload rate by the earner sd,scount. The 

. r j ° carrier s discount will normally be calculated using a base 

a rate not round message. . . , . \ r , , , °„ cnn 

„ , ... , t . .. i M rating engine such as an instance ot standard it 5U0 

The ordered vector utihzed by selective rating engine 102 30 ine object dass U2 ^ vahie of the 

is ordered primarily by a pnon y assigned to each rating tj* ^ ^ & e of the actua , 

engine in the list, and secondarily according to a start date AccordinglV) \ hc W prodllced by aQ insU nce of 

value assigned to each rating engme in be lot A pnonty yp 5( * disc0UQt rati ine wilI not ^ an 

code is mamtamed as an instance vanab e by each base or bm ^ ^ a , vaIue 

collective rating engine. This priority code is used to create 35 „ . . t A , .• • 

" " , / b 7 v J , . . ,-, " reflecting the proper discount. Accordingly, rating engines 

an ordered list of rating engines operated on by a particular , ° 1 1. . u. .-.,«.?<,,,» 

. . 6 £, . . e ■ \a u do not always calculate pnee parameters, but instead may 

collective rating engine. This type of pnonty could be , , / r r , , . ' 

tuiicuivt uimg , v j , , calculate other parameters associated with a rating request. 

implemented in other ways, such as merely by ordering the «...■_ tt . „ 

L r , . \ e / ' • , „, . The term rate is meant to broadly encompass these param- 

objects when creating instances of the rating engines or by 

assigning priority based upon the type of rating engine. Any 40 , . . . . . . » 

of these methods could be used without departing from the An instance of maximum rating engine object c ass 110 

scope of the invention. aod an inslance of minimum rating engme object class 108 

; . r , c 4 . , . „„„„ 4-„, loop through their vector of rating engines and will return 

Another feature of the present invention that allows fast , , . , ^ JL i . .. .■ 1 

. „ . . . . - r i- u 1 tk- the highest cost rate and the lowest cost rate, respectively, 

and efficient calculation of linehaul service rates is the l " ° . . ■ , ■ . r ■ 

r »* At u iu At .„(,•,(, ft,,i ,c * determined by each engine in their vector of rating engines, 

grouping of rating data by the dates on which that data is 45 J b A , . , , 

effective. According to this feature of the invention, a rating Note that rating engine object class 96 is an abstract class 

engine specifies a start date and an end date for which the It is used to define a common interface to all base and 

rating data associated with that object is valid. If the ship collective rating engines. 

date does not fall within the date range, then that rating An example of a rating engine associated with an instance 

engine will return a rate not found message in response to a 50 of carrier contract object class 70 will be discussed in 

request to calculate a rate. In this embodiment, the second- connection with FIG. 8 below. For present purposes, it is 

ary prioritization of the list of rating engines in a collective sufficient to note that the rating engine associated with a 

rating engine is performed in inverse order by start date. particular instance of a carrier contract object class may 

Accordingly, rating engines with equal priority codes having comprise a base rating engine, and/or a collective rating 

start dates that are later in time have a higher priority than 55 engine in combination with one or more additional base 

rating engines with start dates that are earlier in time. rating engines. Each of these rating engines is operable to 

Grouping of rate data according to effective dates allows the calculate a linehaul rate in response to a rating request issued 

data to be located quickly, and also avoids replication of to the instance of carrier contract object class 70. Again, the 

data. Because there may be a large number of items of rating term "linehaul rate" is used broadly with rate having the 

data that have identical start and end dates, creating a rating eo broad meaning discussed above. Although the final result 

engine containing rates with the same start date and end dale calculated by the rating engine will normally be the price for 

avoids the need to store a start date and end date with each linehaul service, a linehaul rate calculated by a particular 

item of rating data. base rating engine or collective rating engine may only be 

In this embodiment, a new rating engine having a different some other type of parameter used to determine the final 

date range is created even if a particular table containing 65 linehaul price. 

1,000 different rates incurs only a few changes due to Each base rating engine object and collective rating 

typographical errors discovered by the carrier. The invention engine object has a method operable to calculate a linehaul 
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Service Description 



rate a ad a rate data structure comprising at least one rate 
value and accessible by the rating method for use in calcu- 
lating a linehaul rate. In this embodiment, each of the 
individual rating engine objects are contained in an instance 
of carrier contract object class 70. The modular rating engine 5 
structure may be implemented in a different way without 
departing from the scope and teachings of the invention. For 
example, rating engines could be used by, rather than 
contained in, a carrier contract object. In addition, rating 
engines could be implemented as methods of the carrier 10 
contract object class. Also, a rating engine could be imple- 
mented as an ordinary software module containing a col- 
lection of procedures and variables. The functions of the 
collective rating engines could be implemented as methods Detention, 
of a carrier contract object that have access to base rating 15 intransit 
engine objects contained in or used by the carrier contract Detention, Trailer 
object. It should also be noted that a carrier contract object 
is broadly defined to comprise a collection of data repre- 
senting contract terms of a contract between a carrier and a 
customer. Carrier contracts could be implemented in a 20 
different formal such that each carrier contract is not repre- 
sented by its own carrier contract object. 

Although the invention includes the base and collective 
rating engines described above, other base rating engines 
and/or collective rating engines could be used in a comput- 25 
erized rating system without departing from the scope of the 
invention. One or more of the collective rating engines 
and/or base rating engines could also be omitted from a 
computerized rating system without departing from the 
scope of the invention. 30 

In addition to the charges for basic linehaul service, 
contracts between a carrier and a customer may include 
charges for a large number of additional services that may be 
applicable to that particular contract. These charges could be 
flat charges, charges billed by the mile, charges by the hour, 
charges by the day, or charges by some other unit. Service 
charges include, but are not limited to, charges for tarps, 
night delivery, or rigging, to name just a few. Also, for 
certain types of shipments, equipment may be rented on a 
per-mile basis by the customer. Such a service would be 
described by the equipment type. Table 1 lists a series of 
services that can be handled by an embodiment of a com- 
puterized rating system constructed in accordance with the 
invention. Table 1 also indicates the unit of measure asso- 
ciated with a particular type of service. "FLT" refers to a flat 
rate unit of measure. "DAY" refers to a charge by the day. 
"HRS" refers to charges by the hour. "MI" refers to charges 
by the mile. "LBS" refers to charges by the pound. "UNT" 
refers to charges by the unit. "WD" refers to charges by per 
one hundred pounds of weight. 

TABLE 1 
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TABLE 1-continued 



Unit of 
Measure 



Service Description 



35 



Customer 
Notification 
Cartage Delivery 
Certified Weight 
Tickets 
Assist Load 
Doubles Charge 
Dual Driver 
Protection Service 
Decontainerize 



Deficit Miles 

Hand Load 
Hand Unload 
Delivery Charge 

Driver Charge 
Direct Shipment 
Dunnage 

Excess Refer Usage 
Equipment Staging 
Fee 
Event 

Expedited Service 
Excess/High Value 

Flatbed Trailer 

Fuel Related 
Adjustment 
Fuel Surcharge 

Canadian Federal 
Tax 

Heated Blanket 
Charge 

Heavy Haul Load 

Hopper Services 
Insurance 
Adjustment 
Intercity Service 



45 



50 





Unit of 




Unit of 


Service Description 


Measure 


Service Description 


Measure 


Second-Day Service 


LBS 


Advancing Charge 


FLT 


Advanced Equipment 


FIT 


Air- Ride Tractor 


FLT 


Auto Store Stop 


FLT 


Backhaul 


MI 


Bobtail Mileage 


MI 


Carrier-Owned 


FLT 




Trailer 




Canadian Bx 


UNT 


Customer Equipment 


aT 


Stop-off 




Return 




Chcps Loads 


UNT 


Continuous Move 


FLT 






Adjustment 




Continuous Move 


FLT 


Consolidation 


FLT 


Charge 




Charge 




Contract Payable 


FLT 


COD. 


FLT 


Canadian Prov. Tax 


FLT 


Crane Charge 


FLT 
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Just In Time 
Layover * Weekend 

Local Work 
Load Delivery 

Labor for Crane 
Linehaul 

Labor Other Than 
Crane 

LTL Discount 
Service 
Miscellaneous 
Allowance 
Miscellaneous 
Charge 

Non-Contracted 
Carrier 

Next Day Service 



New York/Long 
Island 

Overd intension 

Pre Summit CM Bills 

Out of Route 
Pier Charges 
Pallet Exchange 



FLT 

FLT 
FLT 

LBS 
FLT 
FLT 

FLT 
DAY 

DAY 
FLT 

FLT 
FLT 
FLT 

UNT 
FLT 
FLT 
HRS 
FLT 

FLT 
FLT 
FLT 

FLT 

FLT 

MI 

FLT 

FLT 

FLT 

FLT 
FLT 

FLT 

FLT 
FLT 

FLT 
FLT 

FLT 

MI 

FLT 

UNT 

FLT 

FLT 

FLT 

LBS 

FLT 

FLT 

MI 

FLT 

UNT 



Constant 
Surveillance 
Customs Fee 
Commodity Check 

Assist Unload 
Dock Work 
GM Dedicated 
Delivery 

Detention, Driver 
Detention, Rail 
Trailer 
Devanning 
Dedicated Hourly 
Charge 

Deadhead Mileage 
Diversion 
Dispatch of 
Equipment 
Dropdeck Trailer 
Dedicated Contract 
Deficit Weight 
Escort/Pilot Car 
Exclusive Use of 
Vehicle 
Excess Miles 
Expandable Trailer 
Foreign Can 
Cartage 

Foreign Location 
Point 

Ferry Charge 

Full Visible 
Capacity 

Hazardous Material 

Handling Charge 

Hot Parts 
Separation 
Inside Delivery 
(□bond 

International 
Paper/Special 
Service 

Layover - Overnight 
Layover, Overnight 
and Weekend 
Load Delivery 
Labor Disturbance 
Charge 

Lift Gate Service 
Lumper Service 
Lowboy Equipment 

Lift Truck Service 

Mexican Box Stopoff 

Motor Surveillance 

Night Delivery 

New York/Long 
Island Pickup/ 
Delivery 
Ovcrdimension 
Charge 

Order Notify Bill 
of Lading 
Outriggers 
Plant Directed 
Permit Charge 



Unit of 
Measure 



FLT 

FLT 
FLT 

FLT 
HRS 
FLT 

HRS 
DAY 

FLT ' 
HRS 

MI 

FLT 

MI 

FLT 
FLT 
FLT 
FLT 
FLT 

MI 

FLT 

FLT 

FLT 

FLT 

FLT 

FLT 

WD 

FLT 

FLT 
FLT 

FLT 



FLT 
HRS 

FLT 
FLT 

FLT 
UNT 
FLT 

FLT 

UNT 

FLT 

FLT 

FLT 

MI 

FLT 

FLT 
FLT 
FLT 
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TABLE 1-continued 





Unit of 




Unit of 


Service Description 


Measure 


Service Description 


Measure 


Proof of Delivery 


FIX 


Promotional Drop 


FLT 


Power Repositioning 


FLT 


Reconsignment 


FLT 


Required Delivery 


FIX 


Redelivery 


Ml 


Lratc 








Return Empty Charge 


FIX 


Rejected Shipment 


FLT 


Driver Relay 


FLT 


Removable Gooseneck 


FLT 


Rigging Charge 


FLT 


Round Robin Charge 


FLT 


Revenue Share 


UNT 


Satellite Service 


FLT 


Sidewalk Delivery 


FLT 


Shag Service 


FLT 


Shuttle 


FLT 


Sides 


FLT 


Simultaneous 


FLT 


Sold Binders 


FLT 


Pickup/Delivery 




Sold Straps 


FLT 


Slipsfaeet Load 


FIX 


Special Tolls 


FLT 


Sold Winches 


FLT 


Small Package 


FLT 


Satellite Motor 


FLT 




Surveillance 




Supplemental 


FLT 


Stopoff, Peddle Run 


Ml 


Increase 








Spotting 


FLT 


Supervan Trailer 


FLT 


Slipsheet Allowance 


FLT 


Signature Security 
Service 


NULL 


Storage 


DAY 


Stopoff 


FLT 


Saturday Pickup or 


FLT 


Stopoff Service 


FLT 


Delivery 








Sunday/Holiday 


FLT 


Sufferance 


FLT 


Pickup/Delivery 




Warehouse 




Switching Service 


FLT 


Van Refrigerated 


MI 




Van 




45' Van Trailer 


MI 


53' Van Trailer 


MI 


48* Van Trailer 


MI 


45' Van Container 


MI 


40" Van Container 


MI 


20' Van Container 


MI 


48* Van Container 


MI 


53" Van Container 


MI 


48* Flat Bed 


MI 


48' Single Drop 


MI 






Flatbed 




Open Top trailer 


MI 


Concerts Van 


MI 


Air Ride Van 


Ml 


Heated Van 


Ml 


Flat Bed 


Ml 


Flat Bed with Racks 


MI 


Drop Flatbed with 


Ml 


Drop Flatbed with 


MI 


Racks UNCR 




Racks - 12 




Flatbed with Racks 


Ml 


Flatbed with 


MI 


UNCR 




Racks - 12 




Double Drop Flatbed 


Ml 


Double Drop Flatbed 


MI 


with Racks - S 




with Racks • 6 




Road Railer 


ME 


Reefer Stack 


MI 


2ff Export 


Mt 


40' Export 


Mt 


Container 




Container 




45' Export 


MI 


48" Export 


MI 


Container 




Container 




53' Export 


MI 


Piggy Back CTOFC) 


MI 


Container 








Transportatio n 


FLT 




MI 


Consultant 








Through Rate 


MI 


Trailer Interchange 


FLT 


Tire Repair Service 


FLT 


Termination Fee 


FLT 


Tank Trailer 


FLT 


Tolls, Bridge or 


UNT 


Expandable 




Tunnel 




Tier 2 


FLT 


Transaction Fee 


FLT 


On Train 


FLT 


Tractor Usage 


FLT 




FLT 


Trailer Usage 


FLT 


Repositioning 








Terminal Service 


FLT 


Tarps 


UNT 


Trailer Repair 


FLT 


Trailer Size 


FLT 


Service 








Truck/Rail Rate 


FLT 


Tut Service 


FLT 


Test Service 


FLT 


Thru Trailer Charge 


FLT 


Thru Trailer 


FLT 


Unloading Allowance 


FLT 


Mileage 








Van Trailer 


FLT 


Vancouver Island 


FLT 






Mileage 




Vehicie Ordered, 


FLT 


Weighing Charge 


FLT 


Not Used 








Warehouse Service 


FLT 


Cross Dock Charge 


Ml 


EXP REM Gooseneck 


FLT 


XXXX Service 


FLT 


Yard Work 


FLT 


Zee Services 


FLT 
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Like the rating engines described above, service engines 
are designed to process different service rate structures 
which include direct, geography matrices, tiered, and com- 
plex combinations of these structures. Like the rating 

5 engines described above, service engines are modular and 
comprise one or more instances of object classes comprising 
base service engines and collective service engines. Each 
base and collective engine object class inherits from the 
abstract class service engine object class 78. All collective 
service engines inherit from collective service engine object 
class 80 while all base service engines inherit from base 
service engine object class 84. 

Instances of the base service engines of direct service 
engine object class 90, zone zone service engine object class 

15 88 and band value service engine object class 86 contain the 
actual rate data which is made up of service codes, and index 
type (origin/destination type or band type) tiered type (if 
applicable), a unit of measure, and an effective date range. 
In addition to the specific base service engines, there are 

20 collective service engines such as selective service engine 
object class 82. Again, the collective service engines func- 
tion similarly to the collective rating engines, and contain a 
list of other service engines which could be base service 
engines as well as selective service engines, and a method 

25 for processing the rating engines in this list. 

Each service engine for a carrier contract will be for a 
specific service code, of a specific service engine type, tiered 
type (if applicable) unit of measure code, effective start date, 
and effective end date. Service engines may be arranged in 

30 a hierarchical manner using instance variables that indicate 
the parent of a particular rating engine as well as a priority 
instance variable indicating the relative priority between 
service engines. Service engines may also include a dale 
range during which the data stored in that service engine is 

35 valid. Thus, the service engines operate similarly to the 
rating engines. 

In fact, an instance of selective service engine object class 
82 operates identically to an instance of selective rating 
engine object class 102, except for the type of object that it 

40 operates upon. Accordingly, as will be seen in discussing 
FIG. 7, it may be somewhat redundant to have both service 
engine object classes and rating engine object classes. 
Instead, a more complete set of service engine object classes 
can be defined to handle all types of services, including the 

45 linehaul service handled by the rating engine object classes 
in this embodiment. 

In this embodiment, each instance of carrier contract 
object class 70 may also be associated with an instance of 
contract services object class 76. This object class contains 

50 a list of service engines that may be used to calculate the 
price for various services included in a rating request. In this 
embodiment, an instance of contract services object class 76 
is contained in an instance of carrier contract object class 70. 
However, the function of an instance of contract services 

55 object class 76 could be performed by methods and instance 
variables contained in the carrier contract object. 

Tiered services may be implemented with quantity band 
rate structures, which are similar to mileage and weight band 
structures implemented with the rating engines. Quantity 

60 bands will not have any limitation on the ranges, and will be 
tied to the service unit of measure. Tiered services can be 
designated as independent or cumulative. Independent 
means that each service is rated by itself. Cumulative means 
that all services of a specific service code must be rated 

65 cumulatively. An example of a cumulative service rating is 
where stopoff services are stored individually for each stop 
but are rated cumulatively. 
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Cumulative service rating will be accomplished by pass- 
ing in the service that needs rating as well as the vector of 
all services for the request. The service rating method must 
understand that the service charge is cumulative and look for 
other services with the same service code as the one being 
rated. Then it must be determined according to the order of 
stops where the one being rated falls. With this information, 
the service can be rated correctly. 

As noted above with respect to the rating engines, various 
changes can be made in the implementation of these service 
engines without departing from the scope of the invention. 
Some of the changes and alterations include changes and 
alterations similar to those described in connection with the 
rating engines above. 

FIG. 7 illustrates a class diagram of a portion of a second 
embodiment of a computerized rating system constructed in 
accordance with the invention. In this embodiment, the 
rating engine has been eliminated and its functions are 
performed by a service engine. Accordingly, a carrier con- 
tract in such an embodiment is associated only with a 
qualification engine and a service engine. The cost of 
linehaul service, as well as all other services, is calculated by 
the service engine. As noted above, this means that the cost 
of linehaul service calculated by the rating engine in the 
embodiment illustrated in FIG. 6 can be considered to be just 
a special type of service that may be calculated by the 
service engine in this embodiment. The service engines that 
calculate the cost of linehaul service may still be referred to 
as rating engines or may be referred to as service engines. 

Several new object classes have been added to this 
embodiment, including LTL service engine object class 124, 
standard YF 500 discount service engine object class 126, 
zone value service engine object class 128, additive service 
engine object class 130, multiplier service engine object 
class 132, minimum service engine object class 134, and 
maximum service engine object class 136. The function 
performed by instances of these object classes is identical to 
the function of (he similarly named rating engine object 
class in FIG. 6. Here, the engines are more genetically 
referred to as service engines, as they may be used to 
calculate the cost of services other than linehaul services. 
Their operation, however, is similar to the operation of the 
embodiments illustrated in FIG. 6. 

This embodiment of the invention thus provides the same 
modular approach as the embodiment illustrated in FIG. 6, 
although only a single collection of base and collective 
engines making up a service engine is provided. 

FIG. 8 illustrates an object diagram of a portion of a 
carrier contract implemented in accordance with the 
embodiment illustrated in FIG. 6. This carrier contract 
includes carrier contract object 138, additive rating engine 
140, selective rating engine 142, zone value rating engine 
144, zone zone rating engine 146, zone zone rating engine 
148, and zone zone rating engine 150. 

Carrier contract object 138 comprises an instance of 
carrier contract object class 70. Additive rating engine object 
140 comprises an instance of additive rating engine class 
104. Selective rating engine object 142 comprises an 
instance of selective rating engine object class 102. Zone 
value rating engine object 144 comprises an instance of zone 
value rating engine object class 116. Zone zone rating 
engines 146, 148, and 150 comprise instances of zone zone 
rating engine object class 114. 

This example will be used to illustrate how modular rating 
engines can be constructed in accordance with the invention. 
It will also indicate the operation of a rating engine con- 
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structed in accordance with the inverition and illustrate how 
a collective rating engine uses an ordered list of rating 
engines organized according to precedence and date range. 
When carrier contract object 138 receives a rating request, 

5 and determines that it is qualified to process that request, it 
then generates a message that is passed to additive rating 
engine object 140 to calculate a rate. Additive rating engine 
140 contains a vector comprising selective rating engine 
object 142, and zone value rating engine object 144. Addi- 

10 tive rating engine 140 will add the results of the rates 
calculated by selective rating engine object 142, and zone 
value rating engine 144. Accordingly, additive rating engine 
140 first generates a message to selective rating engine 142 
to determine a rate and then generates a similar message to 

15 zone value rating engine 144. After these rates have- been 
calculated, the rates are added and returned to carrier con- 
tract object 138. 

Selective rating engine 142 also maintains an ordered list 
of rating engines, in this case, zone zone rating engine object 

20 146, zone zone rating engine object 148, and zone zone 
rating engine object 150. In this example, the first object on 
the ordered list comprises zone zone rating engine 146 
because this object has a priority value (precedence) that is 
higher than any other object on the list. The second and third 

25 entries on the list are zone zone rating engine object 148 
followed by zone zone rating engine 150. Although zone 
zone rating engine 148 and zone zone rating engine 150 have 
an equal priority value (precedence) zone zone rating engine 
148 has a start date value that is later in time than the start 

30 date value for zone zone rating engine 150. Accordingly, 
zone zone rating engine object 148 has a higher order in the 
list in this embodiment. 

It should be noted that zone zone rating engine object 146 

35 is a zip 5 to zip 5 zone zone rating engine while zone zone 
rating engine objects 148 and 150 are zip 3 to zip 3 type zone 
zone rating engine objects. The higher precedence of the zip 
5 to zip 5 zone zone rating engine may indicate that the 
carrier prefers to bill the customer based upon the five digit 

4Q zip code but will bill the customer based upon three digit zip 
codes in certain instances. 

In operation, the selective rating engine object 142, after 
receiving a message to calculate a rate from additive rating 
engine object 140, will first pass a message to zone zone 

45 rating engine object 146 to attempt to calculate a rate. If zone 
zone rating engine 146 returns a rate, then selective rating 
engine object 142 returns this rate in response to the message 
from additive rating engine object 140. If zone zone rating 
engine 146 returns a rate not found message, then selective 

50 rating engine will send a message to zone zone rating engine 
object 148 in requesting it to calculate a rate. If it returns a 
rate, then that rate would be returned in response to the 
message from additive rating engine object 140. Otherwise, 
if a rate not found message is returned, then selective rating 

55 engine object 142 will then generate a message to zone zone 
rating engine object 150. Selective rating engine object 142 
will then return either (1) the rate returned by zone zone 
rating engine 150 or (2) a rate not found message if zone 
zone rating engine 150 returns a rate not found message in 

60 response to the message generated by selective rating engine 
object 142. 

Each of the zone zone rating engine objects 146, 148, and 
150 will make sure (hat the dale included with the rating 
request falls within the date range specified by the start date 
65 and end date associated with (he particular rating engine 
object. Notice that the dale ranges may overlap. A comput- 
erized rating system constructed in accordance with the 
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invention may maintain rating engines that may no longer be 
used for new shipments because the end date associated with 
that rating engine is now earlier in time than the date on 
which the rating engine is being used. In other words, all of 
the rates associated with that rating engine have expired. The 
rating engine may still be maintained by the computerized 
rating system, however, for purposes of generating bills for 
the shipment, a check, invoice or payment for the shipment, 
and/or for report or auditing purposes. 

Although the present invention has been described in 
detail, it should be understood that various changes, 
substitutions, and alterations can be made hereto without 
departing from the spirit and scope of the invention as 
defined by the appended claims. 

What is claimed is: 

1: An object-oriented rating engine operable to receive a 
rating request associated with a carrier contract, the rating 
engine comprising: 

a first base rating engine object operable for use on a 
computer and further operable to calculate a line haul 
rate in response to the rating request, the first base 
rating engine object comprising an instance of an object 
class that inherits, either directly or indirectly, from a 
base rating engine object class, the first base rating 
engine object further comprising 
a rating method operable to calculate the line haul rate, 
and 

a rate data structure comprising at least one rate value, the 
rate data structure accessible by the rating method for 
use in calculating the line haul rate. 

2. The object-oriented rating engine of claim 1, wherein 
the rating method is operable to calculate a line haul rate of 
a type selected from the group consisting of zip 5 value, zip 
3 value, state value, country value, splc value, zip 5 to zip 

5, splc to splc, splc to zip 3, splc to state, zip 3 to splc, zip 35 
3 to zip 3, zip 3 to state, state to splc, state to zip 3, zip 3 
range to zip 3 range, state to state, country to country, 
mileage band value, yellow 500, yellow 510, and direct 
charge. 

3. The object-oriented rating engine of claim 1, wherein 40 
the first base rating engine object is contained in a carrier 
contract object, the carrier contract object comprising a 
collection of data representing contract terms. 

4. The object-oriented rating engine of claim 1, wherein 
the first base rating eogine object is used by a carrier contract 45 
object, the carrier contract object comprising a collection of 
data representing contract terms. 

5. The object-oriented rating engine of claim 1, wherein 
the first base rating engine object further comprises a start 
date value and end date value collectively denoting a period 50 
of time for which the rate data structure provides valid data. 

6. The object-oriented rating engine of claim 5, wherein 
the first base rating engine object will not calculate the line 
haul rate if a date parameter provided with the rating request 
does not fall within the date range between the start date 
value and end date value. 

7. The object-oriented rating engine of claim 1, wherein 
the first base rating engine object is contained in a contract 
services object, the contract services object containing at 
least one base service engine object, the contract services 
object associated with a carrier contract object, the carrier 
contract object comprising a collection of data representing 
contract terms. 

8. The object-oriented rating engine of claim 7, wherein 
the first base rating engine object further comprises a start 
date value and end date value collectively denoting a period 
of time for which the rate data structure provides valid data. 
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9. The object-oriented rating engine of claim 8, wherein 
the first base rating engine object will not calculate the line 
haul rate if a date parameter provided with the rating request 
does not fall within the date range between the start date 
value and end date value. 

10. The object-oriented rating engine of claim 1, further 
comprising: 

a first collective rating engine object operable for use on 
a computer and further operable to calculate a second 
line haul rate in response to the rating request, the 
collective rating engine object further comprising 

a rating engine data structure operable to maintain an 
association between the collective rating engine object 
and the first base rating engine object and at least a 
second base rating engine object, and 

a collective rating method operable to calculate the sec- 
ond line haul rate in response to the rating request by 
performing an operation on line haul rates calculated by 
the first base rating engine object and the second base 
rating engine object. 

11 . The object -oriented rating engine of claim 10, wherein 
the operation performed by the collective rating method 
comprises a function selected from the group consisting of 
prioritized selection of line haul rates, addition of line haul 
rates, multiplication of line haul rates, minimum line haul 
rate, and maximum line haul rate. 

12. The object-oriented rating engine of claim 10, wherein 
the rating engine data structure is further operable to main- 
tain an association between the collective rating engine 
object and a second collective rating engine object. 

13. The object-oriented rating engine of claim 10, wherein 
the first base rating engine object and the second base rating 
engine object are each operable to return a rate not found 
message if a rate cannot be calculated by that base rating 
engine object in response to the rating request; 

wherein the first collective rating engine object comprises 
a selective rating engine object; 

wherein the rating engine data structure of the first 
collective rating engine object further comprises an 
ordered list of base rating engine objects and collective 
engine objects organized by a priority assigned to each 
base rating engine object and collective engine object; 
and 

wherein the first collective rating engine is further oper- 
able to calculate the second line haul rate in response to 
the rating request, the second line haul rate calculated 
by traversing the rating engine data structure and 
attempting to calculate a line haul rate using a base 
rating engine object or collective rating engine object 
associated with a particular entry on the list, returning 
a line haul rate calculated by the first entry on the list 
for which a line haul rate could be calculated and 
returning a rate not found result if no entry on the list 
could calculate a line haul rate. 

14. The object-oriented rating engine of claim 13, wherein 
each base rating engine object further comprises a start date 
value and end dale value collectively denoting a period of 
time for which the rate data structure provides valid data. 

15. The object-oriented rating engine of claim 14, wherein 
the rating engine data structure is secondarily ordered 
according to the start date value. 

16. An object-oriented rating system, comprising: 

at least one carrier contract object, the carrier contract 
object operable to receive a rating request and operable 
for use on a computer; 

a first base rating engine object operable for use on a 
computer and further operable to calculate a line haul 
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rate in response to the rating request, the first base 
rating engine object comprising an instance of an object 
class that inherits, either directly or indirectly, from a 
base rating engine object class, the first base rating 
engine object further comprising 
a rating method operable to calculate the line haul rate, 
and 

a rate data structure comprising at least one rate value, the 
rate data structure accessible by the rating method for 
use in calculating the line haul rate. 

17. The object-oriented rating system of claim 16, 
wherein the first base rating engine object is contained in the 
at least one carrier contract object, the at least one carrier 
contract object comprising a collection of data representing 
contract terms. 

18. The object-oriented rating system of claim 16, 
wherein the first base rating engine object is contained in a 
contract services object, the contract services object oper- 
able to receive messages from the at least one carrier 
contract object. 

19. The object-oriented rating system of claim 16, further 
comprising: 

a second base rating engine object; 

a first collective rating engine object operable for use on 
a computer and further operable to calculate a second 
line haul rate in response to the rating request by 
performing an operation on line haul rates calculated by 
the first base rating engine object and a second base 
rating engine object. 

20. The object-oriented rating system of claim 16, further 
comprising: 

a plurality of additional base rating engine objects; 

at least one collective rating engine object; 

wherein the first base rating engine object, the additional 
base rating engine objects, and the at least one collec- 
tive rating engine object are associated with one 
another in a tree-like structure such that each base 
rating engine object comprises a leaf node of the 
tree -like structure and each collective rating engine 
object comprises a non-leaf node of the tree-like struc- 
ture. 

21. The object-oriented rating system of claim 16, further 
comprising: 

at least one collective rating engine object operable for 45 
use on a computer, each collective rating engine object 
further comprising 

a rating engine data structure operable to maintain an 
association between the collective rating engine 
object and a plurality of operand rating engine 
objects wherein the operand rating engine objects 
comprise either collective rating engine objects or 
base rating engine objects, and wherein the first base 
rating engine object comprises one of the operand 
rating engine objects and 

a collective rating method operable to calculate a 
second line haul rate in response to the rating request 
by performing an operation on line haul rates calcu- 
lated by at least one of the operand rating engine 
objects. 

22. The object-oriented rating system of claim 21, 
wherein the rating engine data structure comprises an 
ordered list of the operand rating engine objects ordered 
according to a priority assigned to each of the operand rating 
engine objects. 

23. The object-oriented rating system of claim 21, 
wherein each operand rating engine object further comprises 



a start date value and end date value collectively denoting a 
period of time for which the operand rating engine object 
provides valid data; and 
wherein the rating engine data structure comprises an 
ordered list of the operand rating engine objects 
ordered according to the start date value of each of the 
operand rating engine objects. 

24. The object-oriented rating system of claim 23, 
wherein the ordered list is ordered from a latest start date 
value to an earliest start date value. 

25. The object-oriented rating system of claim 22, 
wherein each operand rating engine object further comprises 
a start date value and end date value collectively denoting a 
period of time for which the operand rating engine object 
provides valid data; and 

wherein the rating engine data structure comprises an 
ordered list of the operand rating engine objects 
ordered primarily according to a priority assigned to 
each of the operand rating engine objects and second- 
arily according to the start date value of each of the 
operand rating engine objects. 

26. The object-oriented rating system of claim 21, 
wherein the rating request comprises a date parameter; 

and 

wherein the operand rating engine objects and the at least 
one collective rating engine object further comprise a 
start date value and end date value collectively denot- 
ing a period of time in which the date parameter must 
be included for the operand rating engine objects and 
the at least one collective rating engine object to 
compute a valid line haul rate in response to the rating 
request. 

27. The object-oriented rating system of claim 16, 
wherein the first base rating engine object further com- 
prises a start date value and end dale value, collectively 
denoting a range of ship dates for which each rate value 
in the rate data structure is valid. 

28. A method for processing rating requests in a computer 
rating system, comprising: 

receiving a first rating request with a base rating engine 
object, the base rating engine object operable for use on 
a computer and comprising an instance of an object 
class that inherits, either directly or indirectly, from a 
base rating engine object class, the first rating request 
associated with a carrier contract and comprising 
source data and destination data, wherein (he base 
rating engine object comprises a rating method oper- 
able to calculate a line haul rale, and a rate data 
structure comprising at least one rate value, the rate 
data structure accessible by the rating method for use in 
calculating the line haul rate; 
calculating a first line haul rate using the rating method in 
response to the first rating request. 

29. The method of claim 28, wherein the base rating 
engine object further comprises a start date value and end 
date value collectively denoting a range of ship dates for 
which each rate value in the rate data structure is valid. 

30. The method of claim 29, wherein the step of calcu- 
60 lating the first line haul rate further comprises: 

calculating the firsi line haul rate using the rating method 
in response to the first rating request if a date parameter 
provided with the first rating request falls within the 
date range between the start date value and end date 
value. 

31. The method of claim 28, wherein the base rating 
engine object further comprises a start date value and end 
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dale value collectively denoting a range of ship dates for 
which the base rating engine object is capable of calculating 
the first line haul rate. 

32. The method of claim 31, wherein the base rating 
engine object is contained in a contract services object, the 
contract services object containing at least one base service 
engine object, the contract services object associated with a 
carrier contract object, the carrier contract object comprising 
a collection of data representing contract terms. 

33. The method of claim 28, further comprising: 
receiving a second rating request with a first collective 

rating engine object operable for use on a computer, 
each collective rating engine object further comprising 
a rating engine data structure operable to maintain an 
association between the collective rating engine 
object and a plurality of operand rating engine 
objects wherein the operand rating engine objects 
comprise either collective rating engine objects or 
base rating engine objects, and wherein the base 
rating engine object comprises one of the operand 
rating engine objects, and 
a collective rating method operable to calculate a 
second line haul rate in response to the second rating 
request by performing an operation on line haul rates 
calculated by at least one of the operand rating 25 
engine objects, wherein the collective rating method 
is further operable to generate the first rating request. 

34. The method of claim 33, wherein the rating engine 
data structure comprises an ordered list of the operand rating 
engine objects ordered according to a priority assigned to 30 
each of the operand rating engine objects. 

35. The method of claim 33, wherein each operand rating 
engine object further comprises a start date value and end 
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date value collectively denoting a period of time for which 
the operand rating engine object provides valid data; and 
wherein the rating engine data structure comprises an 
ordered list of the operand rating engine objects 
ordered according to the start date value of each of the 
operand rating engine objects. 

36. The method of claim 33, wherein each operand rating 
engine object further comprises a start date value and end 
date value collectively denoting a period of time for which 
the operand rating engine object provides valid data; and 

wherein the rating engine data structure comprises an 
ordered list of the operand rating engine objects 
ordered primarily according to a priority assigned to 
each of the operand rating engine objects and second- 
arily according to the start date value of each of the 
operand rating engine objects. 

37. A method of organizing rate data in an object oriented 
rating system, comprising: 

associating at least one base rating engine object with a 
carrier contract object, the at least one base rating 
engine object comprising a start date value and an end 
date value, the base rating engine object comprising an 
instance of an object class that inherits, either directly 
or indirectly, from a base rating engine object class; 

creating a rate data structure within the at least one base 
rating engine object, the rate data structure comprising 
at least one rate data value, wherein each rate data value 
in the rate data structure is valid data for calculating a 
line haul rate for a shipment occurring between the start 
date value and end date value. 



